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ABSTRACT 

This  thesis  presents  a  software  implementation  in  JANUS/ADA  of  the  Radar 
Scheduler  process  based  on  previous  thesis  work  developed  for  the  NPS  AEGIS 
Modeling  Project.  The  project  is  an  emulation  of  the  AEGIS  AN/SPY- 1 A  Radar 
Control  Program  for  a  multi-microprocessor  system.  This  thesis  is  a  first  effort  in 
implementing  the  NPS  AEGIS  project  model  in  JANUS/ADA.  Included  are  the  results 
of  the  preliminary  real-time  testing  and  logical  tests  of  the  Radar  Scheduler  module. 


THESIS  DISCLAIMER 

The  reader  is  cautioned  that  computer  programs  developed  in  this  research  may  not 
have  been  exercised  for  all  cases  of  interest.  While  every  effort  has  been  made,  within 
the  time  available,  to  ensure  that  the  programs  are  free  of  computational  and  logic 
errors,  they  can  not  be  considered  validated.  Any  application  of  these  without 
additional  verification  is  at  the  risk  of  the  user. 

Some  terms  used  in  this  thesis  are  registered  trademarks  of  commercial  products. 
Rather  than  attempt  to  cite  each  occurrence  of  a  trademark,  all  trademarks  appearing 
in  this  thesis  are  listed  below  the  firm  holding  the  trademark: 

1.  U.  S.  Government  (AJPO) 

a.     ADA  Programming  Language 

2.  RR  Software.  Inc. 

a.     JANUS/ADA  Programming  Language 

3.  Digital  Research,  Box  579.  Pacific  Grove.  California 
a.     PL/I-80  Programming  Language 

4.  Intel  Corporation,  Santa  Clara,  California 
a.     iSBC  86/12A  Single  Board  Computer 

5.  Zenith  Data  Systems  Corporation 
a.     Z-100  Series  Computer 
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I.  INTRODUCTION 

The  AEGIS  Combat  System  (ACS)  is  an  automated,  rapid  reaction  shipboard 
combat  system.  As  an  automated  combat  system,  it  is  designed  to  control  shipboard 
sensors,  manage  electronic  data  processing,  and  assist  in  the  making  of  time  critical 
combat  decisions  while  simultaneously  engaging  air,  surface,  and  subsurface  threats. 
Additionally  an  AEGIS  platform  posesses  the  capacity  for  defending  its  accompanying 
forces  against  the  same  threats.  To  meet  this  demanding  environment  the  ACS  relies 
on  a  specially  designed  computer  system  to  assist  in  every  phase  of  combat 
engagement. 

At  present  the  computer  system  is  composed  of  three  banks  of  four  processors 
and  up  to  three  uni-processor  AN/UYK-7  computer  systems,  totalling  fifteen  32-bit 
processors.  In  addition,  there  are  six  or  more  AN/UYK-20  16-bit  minicomputers  in 
the  system  making  the  AEGIS  system  the  largest  network  of  computers  dedicated  :o  a 
combat  system.  The  faculty  and  officer  students  at  the  Naval  Postgraduate  School  have 
been  interested  in  ways  to  reduce  the  costs  of  the  ACS  without  compromising  its 
capability.  As  a  result  the  Naval  Postgraduate  School  developed  the  AEGIS  Modeling 
Group  to  study  the  problem.  The  group's  major  goal  and  approach  to  the  problem  is 
to  model  the  AEGIS  Combat  System's  computer  suite  using  multi-microprocessor 
technology  and  the  latest  software  engineering  principles. 

The  feasibility  of  a  multi-microprocessor  approach  was  first  addressed  by 
Gayler's  thesis  [Ref.  1:  p.  15].  Gayler  explains  that  state  of  the  art  advances  in 
microelectronics  should  be  used  as  an  alternate  method  of  processor  implementation  in 
future  AEGIS  platforms.  In  order  to  realize  the  benefits  of  large  scale  integration 
(such  as  reduced  size,  weight,  cost,  and  an  increased  reliability)  a  distributed  multi- 
microprocessor  architecture  was  proposed.  Further  studies  into  the  hardware 
implementation  were  carried  out  in  thesis  work  by  Dilmore  [Ref.  2:  pp.  7-70]  which 
describe  hardware  implementation  for  the  NTS  model.  After  the  hardware  decisions 
were  made  for  the  model,  Riche  and  Williams  [Ref.  3:  pp.  11-232]  laid  out  the  design 
for  the  software  foundation  for  the  AN/SPY- 1 A  radar  control. 

The  NTS  design  of  the  software  places  a  major  emphasis  on  concurrent  process 
management,    both    asynchronous    and    periodic.     A    Multi-Computer    Real    Time 


Executive  (MCORTEX)  was  developed  in  a  sequence  of  six  thesis  projects  to  permit 
parallel  processing  in  each  computer  in  the  multiprocessor  system.  At  present,  thesis 
work  is  being  done  to  provide  concurrent  process  management  by  creating  an  ADA 
language  interface  to  the  MCORTEX  system.  MCORTEX  can  then  be  used  to 
coordinate  the  asynchronous  processes  of  the  ACS's  model  in  a  multi-microprocessor 
environment.  The  main  objective  of  this  thesis  is  to  implement  the  Radar  Scheduler 
process  using  the  JANUS/ADA  programming  language.  This  in  turn  will  provide  a 
major  portion  of  the  overall  model  and  the  opportunity  to  study  the  feasibility  of  real- 
time programming  in  ADA. 

Chapter  II  of  this  thesis  presents  the  software  documentation  principles  for  the 
NPS  model  of  the  ACS.  This  includes  a  discussion  of  the  Janus  Ada  programming 
language  and  an  explanation  of  the  program  documentation  scheme  used  by  the  NPS 
AEGIS  Modeling  Group.  Chapter  III  describes  the  NPS  model  of  the  Radar  Control 
System.  A  functional  description  is  given  for  of  each  the  Radar  Control  Group 
modules  to  be  modeled.  A  more  detailed  description  of  the  Radar  Scheduler  is  provided 
in  Chapter  IV.  Chapter  IV  presencs  the  Radar  Scheduler  design  and  necessary 
documentation  for  the  Radar  Scheduler  source  code.  This  is  the  major  section  of  this 
thesis  which  emphasizes  the  functional  requirements,  data  structure  specifications,  and 
an  explanation  of  the  algorithms  implemented  by  the  Radar  Scheduler  program. 
Chapter  V  provides  information  on  testing  the  algorithms  implemented.  This  includes  a 
discussion  on  the  module  testing  philosophy  for  time  critical  programs  and  the  strategy 
used  in  testing  the  Radar  Scheduler  modules.  Chapter  VI  presents  the  conclusions  and 
recommendations  for  further  research. 
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II.  SOFTWARE  DOCUMENTATION 

A.  SOFTWARE  ENGINEERING  PHILOSOPHY 

The  primary  goal  of  software  engineering  is  to  improve  the  quality  of  software 
products  while  increasing  the  productivity  of  software  engineers.  This  goal  applies  as 
well  to  the  AEGIS  Modeling  Group.  Due  to  the  continuing  turn  over  and  time 
constraints  of  research  students,  it  is  essential  that  this  project  be  based  on  sound 
software  engineering  principles.  In  view  of  this  the  AEGIS  Modeling  Group  has 
adopted  the  following  philosophy.  First,  both  the  design  and  the  source  code  must  be 
clear,  easy  to  understand,  and  modifiable.  Second,  the  model  must  be  constructed 
within  the  constraints  of  the  AEGIS  program  specifications. 

The  first  goai  mentioned  is  achieved  through  a  top  down  modular  design,  using 
structured  programming.  Moreover,  the  documentation  must  also  emphasize  this 
hierarchical  structure  with  the  upper-most  level  ot  documentation  presenting  'he  least 
detailed  view  and  successive  levels  becoming  more  ana  more  detailed.  Tins  way  the 
reader  is  not  overwhelmed  by  details  and  thus  is  more  able  to  grasp  the  structure  of  the 
program. 

The  second  goal  relating  to  program  specifications  is  very  important.  Unless  the 
design  is  based  on  a  firm  knowledge  of  the  program  specification,  the  modeling  effort  is 
in  vain.  Each  module's  documentation  will  include  a  description  of  its  purpose.  All 
modules  are  constructed  so  that  they  obey  the  functional  specifications  of  the  AEGIS 
AN/SPY- 1 A  Radar  Controller  software. 

B.  THE  ADA  PROGRAMMING  LANGUAGE 

The  ADA  programming  language  was  designed  in  accordance  with  the 
requirements  defined  by  the  United  States  Department  of  Defense.  In  general,  these 
requirements  call  for  a  language  with  considerable  expressive  power  over  a  wide 
application  domain  [Ref.  4:  p.  1-1].  Of  particular  interest  in  our  application  is  the 
languages  ability  to  cover  real-time  programming.  To  support  real-time  programming, 
ADA  provides  facilities  to  model  parallel  tasks  and  to  handle  exceptions. 
Unfortunately,  the  ADA  language  implementations  do  not  provide  runtime 
environments  for  multi-single-board  computer  based  systems.  In  order  to  use  the 
multiprocessor   environment,   the   M CORTEX    operating   system  is   used   to   permit 
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parallel  processing  in  the  ADA  language.  In  particular,  use  is  made  of  the 
JANUS/ADA  language,  which  differs  from  the  fully  validated  ADA  primarily  because 
tasking  and  generics  have  not  yet  been  implemented.  Since  the  M CORTEX  operating 
system  is  used  for  parallel  processing,  there  is  no  need  for  the  tasking  features  of  the 
ADA  language,  and  therefore  JANUS/ADA  is  suitable  as  the  programming  language 
to  implement  the  present  version  of  the  AEGIS  model. 

In  the  JANUS/ADA  programming  language  modules  are  composed  of  packages 
that  can  be  separately  compiled.  The  package  usually  contains  a  specification  and  a 
body.  Each  of  these  parts  reside  in  separate  files  for  compilation  purposes.  Files 
containing  the  moduies  specification  have  the  file  type  "LIB".  Files  containing  "he 
package  body  have  been  given  the  default  JANUS/ADA  file  type  "PKG". 

ADA's  enumeration  types  allow  the  user  to  add  clarity  to  the  code  and  program 
at  a  much  higher  level  of  abstraction.  The  clarity  is  achieved  by  creating  data 
structures  that  can  be  easily  read  rather  than  having  to  decipher  their  purpose  in  the 
code. 

C.       PROGRAM  DOCUMENTATION  REQUIREMENTS 

Documentation  of  the  Pvadar  Scheduler  Model  program  in  :his  thesis  is  in 
keeping  with  the  PL/I-80  version  which  was  modeled  after  me  Software  Requirements 
for  the  A7-E  Aircraft  document.  The  requirements  call  for  documenting  design 
decisions  that  will  impact  the  future  development  of  the  program,  what  the  functional 
requirements  of  the  program  are,  what  the  interface  data  structures  are  composed  of, 
how  the  program's  internal  data  structures  were  fashioned,  and  the  modular 
decomposition  of  the  program.   [Ref.  5:  p.  23] 

All  the  design  decisions  which  were  made  for  the  Radar  Scheduler  Model  can  be 
found  in  Chapter  4  which  serves  as  a  module  design  document.  Each  Radar  Scheduler 
module's  design  documentation  contains  the  following: 

1.  A  functional  abstract  description  of  the  module, 

2.  Common  memory  interface, 

a.  Data  structures  consumed, 

b.  Data  structures  produced, 

3.  Internal  process  data  structures, 

a.  Data  structures  consumed, 

b.  Data  structures  produced, 
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4.  Local  module  data  structures, 

5.  A  description  of  the  module  in  an  algorithmic  language. 

Design  decisions  made  for  the  purpose  of  testing  the  Radar  Scheduler  are  documented 
in  Chapter  V. 


--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  7  Dec  86 

--  MODULE  TYPE:  Skeleton  Sample  (Vers  1.0} 

—  PURPOSE:  Depict  format  for  module  source  code 
--  NAME:  Sample  ...  fig2.pkg 

—  This  sampie  module  source  code  skeleton  represents 

—  the  format  to  be  used  in  documenting  modules. 

WITH  global. tables;    -  declare  global  data  structures 

--  and  common  memory 
PACKAGE  BODY  fig2  IS 

USE  global. tables; 

TYPE  localvar  IS  INTEGER;   --  declare  any  local 
var:  localvar;  --  module  variables 

PROCEDURE  sample! parameter:  IN  INTEGER)  IS 
procvar:  INTEGER;    --  declare  procedure  variables 

BEGIN 

--  code  for  the  procedure 
END  sample: 

BEGIN 

--  If  desired  local  or  global  variables 
--  can  be  initialized  here. 

—  If  this  module  was  not  designed  for  the 
--  procedure  "sample"  then  the  code  for  the 

—  main  program  '  sample"  would  go  here. 
END  fig2; 


Figure  2.1     Source  Code  Documentation. 

Code  documentation  must  maintain  a  balance  between  verbosity  and  scarcity  of 
comments.  The  prime  objective  is  to  increase  readability  and  ease  the  task  of 
maintenance.  An  example  of  the  format  for  source  code  documentation  in  this  thesis  is 
given  in  Figure  2.1  .  The  source  code  documentation  used  in  this  thesis  can  be 
generally  broken  into  three  parts,  a  module  header,  a  module  description,  and  short 
comments  for  code  explanations  that  may  not  be  apparent  to  the  reader. 

The  purpose  of  the  module  header  is  to  introduce  the  module  to  the  reader.  The 
header's  template  format  helps  to  insure  that  vital  information  is  not  overlooked,  while 
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adding  to  the  structured  approach  of  the  documentation.  Each  module  header  provides 
the  reader  with  the  following  information: 

1.  Who  the  owner  of  the  module  is. 

2.  The  date  that  the  module  was  last  altered. 

3.  The  type  of  module  and  the  current  version  number. 

4.  The  purpose  for  which  the  module  was  written. 

5.  The  English  language  equivalent  name  of  the  module  and  the  file  name  it  is 
stored  under. 

Following  the  module  header  is  the  module  description.  The  module  description 
is  used  to  explain  the  generai  functional  logic  which  controls  the  execution  of  the 
algorithm  implemented  by  the  module.  Included  in  the  module  description  are  the 
input  and  output  parameters  used  by  the  module. 

The  last  type  of  documentation,  short  in  code  comments,  are  used  to  introduce 
the  major  functions  within  "he  module.  The  comments  will  describe  what  the  function 
has  been  designed  to  do. 

D.       VARIABLE  NAMING  CONVENTIONS 

A  common  pitfall  of  the  applications  programmer  is  "excessive  contraction"  of 
variable  names.  In  keeping  with  the  desire  to  maximize  readability,  the  convention  for 
naming  variables  is  based  on  two  principles.  First,  that  the  variable  name  be  long 
enough  to  be  unique  to  the  language  and  the  reader,  and  second,  that  the  name  reflect 
the  variables  purpose.  However,  if  the  lengths  of  the  variable  names  are  too  long,  it 
becomes  difficult  to  organize  the  source  code  to  fit  on  the  standard  8.5  inch  by  1 1  inch 
page.  Consequently  the  programmer  must  consider  the  fact  that  he  will  not  be  the  only 
one  to  read  his  code  and  decide  accordingly. 

In  the  case  of  this  thesis  variable  naming  was  based  on  the  PL/I-80  version 
names.  The  reason  for  this  decision  was  to  avoid  confusion  on  the  part  of  future 
researchers.  This  was  necessary  since  the  majority  of  the  variables  are  defined  by 
common  memory  interface  data  structures  that  were  designed  in  the  early  stages  of  the 
Radar  Control  Group  modeling  process.  Since  these  data  structures  act  as  interfaces  to 
the  other  major  processes,  adding,  changing,  or  deleting  variables  in  these  data 
structures  was  not  a  decision  that  should  be  made  from  the  Radar  Scheduler  processes 
design  level. 


14 


E.       FILE  NAMING  CONVENTIONS 

A  file  naming  convention  has  been  established  in  order  to  keep  track,  of  the  large 
number  of  files  that  make  up  the  the  Radar  Controller  model.  This  convention  has 
been  preserved  by  this  thesis  in  order  to  maintain  consistance  with  the  previous 
versions.  The  J  ANUS/ ADA  modules  in  this  thesis  have  been  named  after  their  PL/ 1-80 
predecessors  so  that  their  names  will  serve  as  a  cross-referencing  tool  to  facilitate 
future  research. 


TABLE 

1 

NPS  AEGIS  MODULE  NAMING  CONVENTION 

MODULE  NAME 

CODE     FILE 

NAME 

CONTROL  GROUP 

Radar  Scheduler 

R 

RRCM 

Search  Management 

S 

SRCM 

Track  Management 

T 

TRCM 

Radar  Return  (  incut) 

I 

IRCM 

Radar  Output: 

0 

ORCM 

Channel  I/O  Control 

H 

HRCM 

SUPPORT  CROUP 

Switch  Action  and  Display 

A 

ARCM 

ZCcD    User  Services 

C 

CRCM 

Beam  Stabilization 

3 

BRCM 

Detection  Processing 

D 

DRCM 

ECM/Clutter  Processing 

E 

ERCM 

Frequency  Management 

F 

FRCM 

Track  Association 

K 

KRCM 

Load  Evaluation 

L 

LRCM 

Missile  Communications 

M 

MRCM 

WCS  User  Services 

W 

WRCM 

Cross-Gating 

X 

XRCM 

The  scheme  for  naming  the  files  is  presented  in  Table  1  .  Each  of  the  major 
processes  is  assigned  a  unique  one  letter  process  identifier  code.  This  code  followed  by 
the  letters  "RCM",  make  up  the  file  name  which  stands  for  "Radar  Control  Module". 
Each  of  these  major  processes  is  composed  of  several  subordinate  modules.  The  file 
names  of  the  subordinate  modules  correspond  to  the  initials  of  their  parent  process 
followed  by  a  module  number.  For  example,  the  first  module  within  the  Switch  Action 
and  Display  process  would  have  the  file  name  "SADM1"  which  stands  for  Switch 
Action  and  Display  Module  1. 
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If  the  modules  are  further  subdivided  into  submodules  and  subroutines  then  they 
are  uniquely  identified  through  file  name  typing.  That  is,  the  filename  takes  on  the 
parent  process  initials  and  module  number  followed  by  a  submodule  letter  (A-Z).  For 
instance,  the  Track.  File  Initialization  module,  DPMI,  which  is  part  of  the  Detection 
Processing  Module,  has  a  subroutine  which  is  used  to  place  a  node  at  the  end  of  a 
linked  list.  Since  this  subroutine  is  part  of  DPMI,  it  has  the  file  name  DPMI  A. 

Some  subroutines  may  be  used  by  many  modules.  In  this  case  they  have  more 
than  one  parent  process  and  are  classified  as  "Common  Service  Routines".  These 
modules  use  the  file  name  "CSR"  followed  by  a  number  To  uniquely  identify  them  from 
other  'Common  Service  Routines".  For  example,  the  subroutine  'rand"  .  which 
generates  a  pseudo-random  number,  is  shared  by  several  modules,  therefore,  it  has  the 
file  name  "CSR5".  There  is  aiso  one  other  module  which  is  shared  by  the  major 
processes.  This  module  contains  giobai  data  structures  and  its  file  name  is  'GLOBAL". 

The  Radar  Control  Moduie  aiso  incorporates  files  that  contain  data  structures 
which  ict  as  a  "common  memory  interface'  between  tne  maior  processes.  These 
common  memory  interfaces  are  called  'tables"  and  their  'lie  names  are  the  initials 
"TAB"  followed  by  a  number  (0-77).  The  table's  file  names  are  organized  into  the 
matrix  presented  in  Table  2  .  This  table  shows  data  structures  which  interface  with  the 
major  processes.  The  columns  of  the  matrix  contain  entries  which  identify  tables  usea 
as  the  input  data  structures  to  the  process  identified  by  the  letter  on  top  of  the  column. 
The  rows  of  the  matrix  contain  entries  that  identify  the  tables  which  are  used  as  output 
data  structures  from  the  process  identified  by  the  letter  in  the  left  most  column  of  the 
matrix.  For  example,  "TAB3"  is  an  interface  data  structure  between  the  Radar  Return 
process  (I),  and  the  Radar  Scheduler  process  (R).  To  the  Radar  Return  process 
"TAB3"  is  an  input  data  structure  and  to  the  Radar  Scheduler  process  it  is  an  output 
data  structure. 

Since  all  the  modules  are  defined  as  Ada  packages,  some  modules  may 
incorporate  two  files,  the  package  specification  and  the  package  body.  To  distinguish 
between  them,  the  file  containing  the  specification  has  the  file  type  "LIB".  The  file 
containing  the  body  has  the  file  type  "PKG".  For  example,  the  files  "RRCM.LIB"  and 
"RRCM.PKG"  are  collectively  the  Radar  Scheduler  process.1 


Unless  specified  the  words  process,  module,  submodule,  subroutine,  etc.,  in  this 
thesis  refer  to  the  entire  package  data  structure. 
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TABLE  2 

COMMON  MEMORY  INTERFACE  MATRIX 

CONTROL   GROUP            1                         SUPPORT   GROUP 
RSTP       IOHACBDEFKLMWX 

R" 

0 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

S 

11 

0 

12 

13 

14 

15 

16 

T 

17 

0 

18 

7 

19 

P 

20 

21 

22 

23 

24 

25 

26 

27 

10 

28 

29 

I 

30 

31 

0 

32 

33 

34 

35 

36 

37 

38 

10 

39 

H 

40 

40 

A 

41 

42 

43 

44 

45 

46 |        j  47 

C 

48 

49 

50 

51 

52 

53 

3 

54 

55 

56 

D 

57 

4 

58 

Z 

59 

60 

F 

61 

1 

£  0 

53 

K 

64 

L 

65 

66 

67 

68 

M 

10 

69 

W 

70 

71 

72 

X 

73 

74 

75 

76 

77 
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III.  NPS  MODEL  OF  THE  AN/SPY-1A  RADAR  CONTROL  GROUP 

The  NPS  model  of  the  AEGIS  system  is  designed  to  emulate  the  Radar  Control 
system.  The  overall  system,  as  described  by  Gayler  [Ref.  1:  p.  1],  contains  seven 
subsystems: 

1.  Radar  System  AN/SPY- 1 A 

2.  Command  and  Decision  System  MARK  1  MOD  0 

3.  Weapons  Control  System  MARK  1  MOD  0 

4.  Fire  Control  System  MARK  99  MOD  1 

5.  Guided  Missile  Launching  System  MARK  26  MOD  5 

6.  Standard  Missile 

7.  Operational  Readiness  Test  System  MARK  1 

Research  at  NPS  is  focused  on  the  first  of  these  subsystems.  The  NPS  AEGIS  model 
implements  a  subset  of  the  Radar  Control  Group  subsystem,  which  in  turn  is  a  subset 
of  the  Radar  System  AN' SPY- 1  A.  The  reasons  for  this  decision  are  discussed  in 
Dilmore  s  thesis  [Ref.  2:  pp.  1-20]. 

The  radar  controller  modules  have  been  broken  down  into  two  major  groups: 
control  modules  and  support  modules.  The  control  modules  are  dedicated  to  the  five 
major  tasks  of  the  radar  controller: 

1.  Search  Management, 

2.  Radar  Scheduling, 

3.  Radar  Output, 

4.  Radar  Input  and, 

5.  Track  Processing. 

The  support  modules  perform  more  limited  or  specialized  functions.  Only  the  support 
modules  required  to  implement  the  Radar  Scheduler  will  be  presented  in  this  thesis. 

A.       RADAR  CONTROL  GROUP  MODULES 

This  section  gives  an  overall  view  of  the  Radar  Control  Group  modules  required 
for  the  modeling  of  the  Radar  Scheduler  process.  The  first  subsection  describes  the 
"control  modules"  and  the  second  subsection  is  dedicated  to  the  "support  modules". 
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1.  Control  Modules 

Four  of  the  five  "control"  modules  are  required  to  model  the  Radar  Scheduler 
functions:  the  Radar  Scheduler  process,  the  Search  Management  process,  the  Track 
Management  process,  and  the  Radar  Return  process.  Of  these  control  modules  only 
the  Radar  Scheduler  is  fully  modeled.  The  remaining  control  modules  are  at  present 
only  test  harnesses  for  the  Radar  Scheduler  process.  The  following  description  of  these 
modules  is  based  on  previous  thesis  work.  [Refs.  3,5:  pp.  43-50,  32-36]. 

a.  Radar  Scheduler 

The  Radar  Scheduler's  purpose  is  r.o  schedule  a  mix  of  radar  events.  These 
events  actually  correspond  to  the  transmission  of  a  radar  beam  in  a  specific  direction 
for  a  certain  amount  of  time.  In  doing  this  the  scheduler  must  ensure  that  a  search 
volume  of  360  degrees  azimuth  and  90  degrees  elevation  is  covered.  The  term  "mix  of 
radar  events"  refers  die  various  rvpes  of  events  ,uch  as  search,  track.,  missile  control. 
etc..  Each  of  these  events  has  a  cenain  pnontv  which  must  be  taken  into  account  ro 
insure  its  timely  occurance.  The  time  limit  for  scheduling  a  mix  of  radar  events  in  i 
given  radar  interval  is  21  milliseconds.  For  this  reason  the  Raaar  Scheduler  is  the  most 
time  critical  function  within  the  Radar  Control  Group  ro  be  modeled.  A  more  derailed 
description  of  the  module's  mnctions  will  be  given  in  the  Rauar  .Sciieciuler  Design 
chapter. 

b.  Search  Management 

The  Search  Management  module  generates  all  the  search  type  beam 
requests.  The  requests  fall  into  three  general  categories,  horizon  search,  above  horizon 
search,  and  special  request  type  beams.  The  beams  are  maintained  in  separate  queues 
in  accordance  with  the  operational  doctrine,  the  special  request  doctrine,  and  the  radar 
event  priority  list. 

The  Search  Management  module  must  insure  that  enough  horizon  and 
above  horizon  requests  are  generated  for  a  360  degree  azimuth  and  90  degree  search 
field.  These  two  event  types  may  be  considered  typical  for  normal  operation. 

On  the  other  hand,  special  request  beams  correspond  to  events  which 
would  not  be  considered  under  normal  searching  operations.  The  special  request 
category  contains  eleven  radar  event  types,  which  enhance  the  radar  search  capability. 
The  capabilities  provided  by  the  special  request  events  are  explained  in  the  remainder 
of  this  subsection. 
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Two  of  the  special  request  events  are  devoted  to  ECM  Burnthrough.  ECM 
Burnthrough  is  an  electronic  counter  measure  whereby  the  radar's  transmission  power 
is  increased  so  that  objects  can  be  seen  through  jamming  and/or  clutter.  Jamming  is  an 
electronic  warfare  technique  used  against  radar  to  distort  the  radar  return  being  viewed 
on  the  scope.  Clutter  is  a  term  used  to  describe  extraneous  blips  on  the  radar  scope. 
The  blips  are  usually  caused  by  bad  wether  or  sea  conditions. 

Special  scans  requests  are  also  controlled  by  the  Search  Management 
process.  Special  scans  include  manual  and  moving  target  indicator  (MTI)  search 
requests.  MTI  is  a  technique  that  electronically  filters  out  stationary  objects  from  the 
radar  display,  thereby  indicating  which  objects,  or  targets,  are  actually  moving. 

The  Search  Management  module  controils  passive  search.  In  a  passive 
search,  unlike  active  search,  the  radar's  transmitter  is  off  and  the  radar's  receiver  is 
only  used  to  detect  the  presence  of  another  emmiter. 

The  extended  search  mode  is  another  capability  that  is  controlled  by  the 
Search  Management  orocess.  This  is  used  when  there  ire  several  contacts  along  the 
same  azimuth  and  the  radar  returns  from  the  contacts  become  difficult  to  distinguish. 
Electronic  blanking  gates  are  inserted  at  the  ranges  of  known  contacts  along  the  given 
azimuth  so  that  the  other  contacts  may  be  detected.  The  extended  search  mode  may 
aiso  be  used  to  increase  the  search  intensity  in  either  range  or  bearing. 

Horizon  confirmation  is  an  electronic  means  used  to  confirm  targets  in  a 
clutter  environment.  Horizon  confirmation  and  the  clutter  mapping  process  are  both 
supported  by  the  Search  Management  process. 

The  remaining  special  request  functions  supported  by  the  Search 
Management  module  are  missile  and  target  acquisition  requests,  and  partial  dwell 
formatting  of  the  requested  beams.  Modeling  of  the  partial  dwell  formatting  for  use  by 
the  Radar  Scheduler  would  require  the  use  of  classified  documents.  In  order  to 
maintain  the  unclassified  status  of  this  thesis,  unclassified  data  has  been  substituted  in 
the  requested  beam  queues. 

c.    Track  Management 

The  Track  Management  module  is  responsible  for  controlling  all  the 
requested  track  beams.  Controlling  the  requested  track  beams  entails  three  major  tasks, 
with  respect  to  both  real  and  simulated  targets. 

The  first  task  is  track  updating.  Track  updating  entails  an  automatic 
smoothing  of  the  position  and  rate  of  target  return  data.    This  data  is  used  to  predict 
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the  future  target  positions  with  sufficient  accuracy  to  maintain  tracking.  In  order  to 
accomplish  this,  the  Track.  Management  process  must  ensure  that  the  highest  priority 
tracks  are  given  ample  illumination  time  by  the  radar  while  simultaneously  keeping 
lesser  priority  tracks  illuminated  within  the  constraints  necessary  to  maintain  their 
tracks.  When  the  system  becomes  overloaded,  the  software  must  be  able  to  compensate 
by  eliminating  those  tracks  that  are  perceived  as  least  threatening.  Naturally,  this  also 
implies  that  track  processing  must  be  able  to  evaluate  new  targets  immediately  so  that 
special  threat  candidates  and  target  splits  can  be  identified. 

The  second  task  is  track  handling.  Track  handling  includes  the  following: 

1.  Track  dwell  wave  form  selection, 

2.  Cross-gate  preparation, 

3.  Transition  from  search  to  track  mode, 

4.  Acceleration  limiting  processing,  and 

5.  Automatic  special  mode  processing. 

The  third  task  is  special  processing.  Special  processing  is  a  collection  of 
routines  used  for  JVLTI  tracks,  missile  tracks,  and  clock  updates.  Special  processing  also 
includes  a  routine  for  handling  split  targets.  A  split  target  is  actually  two  or  more 
targets  that  initially  appear  as  one  because  they  are  so  close  together.  When  the  "arget 
does  split  into  multiple  tracks  each  must  be  individually  processed. 

Special  processing  also  includes  a  routine  for  processing  Sensitivity  Time 
Control  (STC)  data.  STC  is  an  electronic  adjustment  to  the  gain  of  the  radar  receiver 
based  on  the  radar  range  to  the  target.  This  keeps  objects  closest  to  the  radar,  which 
provide  very  strong  returns,  from  saturating  the  radar  returns. 

In  conjunction  with  the  three  functions  previously  mentioned,  the  Track 
Management  module  is  responsible  for  notifying  Command  and  Decision  (C  &  D)  and 
Weapons  Control  Systems  (WCS)  of  new  tracks  and  any  special  threats. 
d.   Radar  Return  {Input) 

The  Radar  Return  module  performs  the  initial  processing  on  the  raw  data 
received  from  the  SPY-1A  Signal  Processor.  This  includes  data  validity  checks,  clutter 
mapping,  search  processing,  track  angle  error  correction,  and  ECM  analysis. 

Once  this  is  accomplished,  the  radar  data  must  be  routed  to  the  appropriate 
modules  for  further  processing.  Evaluation  and  dissemination  of  this  data  is  subject  to 
the  same  21  millisecond  time  constraint  as  the  Radar  Scheduler.  In  fact  the  Radar 
Scheduler  relies  on  synchronization  data  from  the  Radar  Return  module  to  maintain 
scheduling  interval  synchronization  with  the  radar  hardware. 
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2.  Support  Modules 

There  are  fifteen  "support  modules"  contained  in  the  Radar  Control  Group 
Modules.  These  support  modules  function  as  background  processes  to  provide  support 
for  the  "control  modules".  Seven  of  these  modules  are  required  for  modeling  the  Radar 
Scheduler  function.  The  description  of  these  modules  is  based  on  information  supplied 
in  previous  thesis  research  for  the  AEGIS  Modeling  Group  [Refs.  5,3:  pp.  36-40, 
51-55]. 

a.  Switch  Action  and  Display 

The  Switch  Action  and  Display  module  acts  as  an  interface  between  the 
Radar  System  Controller  (RSO  and  the  radar.  This  allows  the  RCS  to  monitor  and 
control  the  radar  in  accordance  with  operational  doctrine  and  the  individual  desires  of 
the  operator. 

The  module  provides  information  to  the  Radar  Scheduler  function  which  is 
used  in  formatting  selected  beams  for  the  current  scheduling  interval.  The  information 
consists  of  inhibited  radiation  regions  and  the  radiation  power  level  (low  or  high). 
Radiation  inhibit  regions  are  regions  where  doctrine  control  does  not  ailow  radar 
transmission.  The  regions  are  defined  via  start  and  stop  bearings. 

b.  Command  and  Decision  User  Services 

The  Command  and  Decision  User  Services  moduie  acts  as  an  interface 
between  the  Radar  Control  Group  and  the  Command  and  Decision  Group.  The 
purpose  of  the  module  is  to  check  and  route  all  the  messages  between  these  programs. 
To  accomplish  this,  a  priority  level  message  scheme  is  used  in  order  to  meet  the 
required  track  report  interval  rates  and  other  report  rates  during  peak  radar  load 
periods. 

c.  Beam  Stabilization 

The  Beam  Stabilization  module  performs  two  main  functions.  First  it 
transforms  the  ship's  motion  matrix  (roll,  pitch,  and  yaw)  into  a  stable  space  matrix 
which  is  used  for  radar  beam  guidance.  Second,  it  assigns  the  array  face  limits  which 
are  used  in  formatting  scheduled  dwells. 

The  fore  and  aft  gyro  data  converters  supply  the  necessary  roll,  pitch,  and 
yaw  information  along  with  ship's  heading  for  stabilization.  This  information  is  used 
to  compute  the  stable  deck  space  matrix. 

The  ship's  motion  matrix  and  the  bearing  limits  for  the  four  phased  array 
antennas  are  passed  to  the  Radar  Scheduler.  The  Radar  Scheduler  then  uses  the 
information  to  format  the  selected  dwells. 
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d.  Detection  Processing 

The  Detection  Processing  module  is  executed  only  when  target  or  beacon 
detection  data  is  received  from  the  Radar  Return  module.  When  this  occurs  the 
module  looks  for  detections  as  a  result  of  normal  search  (clear  and  MTI),  extended 
range  search,  horizon  confirmation,  missile  acquisition,  and  target  acquisition  dwells. 
The  module  is  also  responsible  for  initiating  track  requests  and  preparing  detections  for 
cross-gating. 

The  Track  File  data  is  maintained  by  the  Detection  Processing  module.  The 
Track  file  is  a  linked  list  data  structure  capable  of  handling  as  many  targets  as  can  be 
tracked  within  the  hardware  constraints  of  the  computer.  Access  to  the  Track  File  is 
provided  to  the  Radar  Scheduler  by  the  Track  Management  module  via  an  index  into 
the  file. 

e.  Frequency  Management 

The  Frequency  Management  module  is  used  to  assign  radar  frequencies  to 
the  dwells  selected  by  the  Raaar  Scheduler  during  each  scheduling  interval.  The 
frequencies  and  onase  codes  assigned  to  the  dwell  are  made  to  conform  with  sector  ana 
global  doctrines. 

fn  accordance  with  the  doctrines,  frequency  channel  selections  are  in  one  of 
three  modes,  fixed,  random,  or  preiook.  Fixed  implies  one  designated  cnannei  only.  The 
random  mode  means  that  frequencies  are  selected  on  a  random  basis  from  the  available 
channels  established  by  the  current  doctrine.  Preiook  implies  frequency  selection  of  the 
least  jammed  channel  frequency  based  on  the  results  of  a  passive  angle  track  (PAT) 
frequency  analysis.  By  use  of  these  frequency  channel  selection  modes  the  Frequency 
Management  module  can  generate  the  Radar  Scheduler  input  data  for  the  frequency 
operating  channel  and  subpulse-frequency  order  selection. 

The  phase  code  to  be  used  within  each  dwell  is  also  specified  by  this 
module.  The  phase  codes  are  selected  at  random  from  a  list  of  the  phase  codes 
available  during  the  current  schedule  for  each  dwell.  A  separate  list  of  phase  codes  are 
maintained  for  clear  and  MTI  type  dwells. 

Each  scheduled  dwell  will  contain  channel  frequency,  band  frequency, 
phase  codes,  and  inhibited  frequency  channels.  If  the  dwell  is  an  MTI  type  then  it  will 
also  contain  MTI  frequency  data.  If  the  dwell  is  a  missile  type  then  missile  uplink  and 
downlink  frequencies  will  be  included. 
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/.    Load  Evaluation 

The  Load  Evaluation  module  provides  system's  load  information  to  the 
Command  and  Decision  element  as  well  as  the  Radar  System  Controller.  The  systems 
load  is  based  on  seven  indicies  which  must  be  computed  periodically.  These  seven 
indicies  are: 

1.  Transmitter  utilization  load, 

2.  Control  group  track  file  load, 

3.  Control  group  computer  processing  load, 

4.  Search  frame  time  for  horizon  and  above  horizon  scans. 

5.  Track  time, 

6.  Track  transition  index,  and 

7.  Radar  time  utilization  index. 

The  track  cime  variable  is  used  by  the  Raaar  Scheduler  as  input  to  reset  us' 
track  time  counter.   The   Radar  Scheauler  .veeps  a  running  total  ot  track  time.    rhe 
Track  time  inaex  orovuies  :ne  percentage  of  radar  usage  dedicated  to  tracKing  targets 
over  an  average  live  second  time  span. 
g.    Missile  Communication 

The  Missile  Communication  moauie  provides  an  interface  between  the 
Weapons  Control  System  guidance  command  generation  ana  Radar  Control  Program  s 
guidance  control  link.  Uplink  missile  guidance  commands  and  the  missile  identification 
code  are  sent  to  the  Radar  Scheduler.  Further  information  on  the  operation  of  this 
function  can  be  found  in  classified  documents. 
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IV.  RADAR  SCHEDULER  DESIGN 

The  design  of  the  Radar  Scheduler  function  is  based  on  the  PL/I-80  version 
implemented  by  Grant,  [Ref.  5:  p.  41].  This  chapter  presents  the  design  details  for  the 
JANUS/ADA  version  of  the  Radar  Scheduler  process. 

A.   PURPOSE  OF  RADAR  SCHEDULER 

The  Radar  Scheduler's  purpose  is  to  schedule  a  mix  oC  radar  events  (dwells)  in  a 
way  that  ensures  the  occurrence  of  necessary  events  in  a  timely  manner.  The  various 
types  of  radar  events  used  in  this  model  were  taken  from  open  literature,  rather  than 
the  actual  classified  list  found  in  the  AEGIS  performance  specifications.  [Ref.  5:  p  41] 
The  list  of  radar  events  shown  in  Tabie  3  are  the  radar  events  used  in  this  model. 


TABLE  3 
RADAR  EVENT  PRIORITY  LIST 

PRIORITY   RADAR  EVENT  QUEUE  IDENTITY 

1  ECM  Burnthrouqh  Special  Request 

2  Target  Definition  Special  Request 

3  Special  Test  Special  Request 

4  Engaged  Hostile  Target  Track 

5  Own  SM-2  Missile  Guidance  Missile 

6  Pre-Engaged  Hostile  Target  Track 

7  High  Priority  Track  Transition         Track 

8  High  Priority  Track  Confirmation       Track 

9  Horizon  Search  Search 

10  Special  ECM  Burnthrouqh  Special  Request 

11  Special  Target  Definition  Special  Request 

12  Special  Scans  ( MTI , Man, etc)  Special  Request 

13  Special  Target  Acquisition  Special  Request 

14  Confirmed  Hostile  Track  Track 

15  Assumed  Hostile  Track  Track 

16  Unevaluated  Track  Track 

17  Controlled  Friendly  Track  Track 

18  Track  Confirmation  Track 

19  Track  Transition  Track 

20  Assumed  Friendly  Track  Track 

21  Confirmed  Friendly  Track  Track 

22  Above  Horizon  Search  Search 

23  Above  Horizon  Search  Test  Special  Request 

24  Simulation  Dwell  Special  Request 

25  Diagnostic  Dwell  Special  Request 

26  Dummy  Dwell  Special  Request 
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The  actual  mix  of  radar  events  that  get  scheduled  is  determined  by  the  Radar 
Scheduler.  The  schedule  is  governed  by  the  radar  resources  available,  time  constraints, 
and  an  event's  priority  relative  to  the  other  events  that  are  being  requested.  The  details 
of  the  process  are  explained  in  the  following  section.  The  Radar  Scheduler's 
algorithmic  description  is  given  Figure  4.1  . 


Begin  Radar  Scheduler; 

7or  number  of  intervals  loop; 

Advance  radar  Iood  event  counts; 

Get  value  of  real  time  (CSR7); 

Swap  external  dwell  buffers  (RSM2); 

Do  enhancement  of  Radar  Event  Priorities  (RSM3); 

Resynchronize  computer  and  radar  times  (RSM4) ; 

Begin  beam  selection 

Traverse  the  Priority  List 
Traverse  the  event  queue 
If  searcn  or  special  request  queue  then 
Put  beam  information' in  Control  Taole; 
Do  Supplementary  Dwell  Processing  IRSM6); 
Do  Face  Assignment  (RSM7); 
Do  Radar  Doctrine  (RSM8) : 
Satisfy  Hardware  Constraints  (RSM9); 
If  satisfied  then 

rill  External  Tables  (RSH10); 
Insert  Dwell  in  Control  Table  list  (RSH5); 
Else 

Delete  Dwell  from  Control  Table  list  (RSM5); 
Else 

Put  beam  information  in  Control  Table; 

Do  Supplementary  Dwell  Processing  (RSM6); 

Do  Face  Assignment  (RSM7); 

Do  Radar  Doctrine  (RSM8) j 

Satisfy  Hardware  Constraints  (RSM9); 

If  satisfied  then 

Fill  External  Tables  (RSM10); 
Insert  Dwell  in  Control  Table  list  (RSM5); 
Else 

Delete  Dwell  from  Control  Table  list  (RSM5); 
End  Traverse  the  Event  Queue; 
Compute  Elapsed  Time  (RSM12); 
End  Traverse  Priority  List; 
End  Beam  Selection; 
If  interval  results  are  to  be  displayed  then 

Display  Interval  Scheduling  Results  (RSM13); 
Free  Control  Table  Memory  for  Next  Interval  (RSM14); 
End  For  number  of  intervals  loop; 
End  Radar  Scheduler; 


Figure  4.1  Radar  Scheduler  Algorithm. 
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B.       FUNCTIONAL  DESCRIPTION  OF  RADAR  SCHEDULER 

The  Radar  Scheduler  operates  in  a  continuous  loop  selecting  requested  beams, 
generated  by  the  Search  and  Track  management  processes,  for  scheduling.  Once 
selected,  the  beams  are  formated  into  dwells.  If  the  hardware  and  other  constraints  are 
satisfied,  then  scheduled  dwells  are  sent  to  the  Radar  Output  function  and  are  packed 
into  the  Channel  Output  Buffer  for  transmission  to  the  Signal  Processor.  The  time  it 
takes  to  complete  this  task  is  defined  as  a  scheduling  interval.  Furthermore,  the  median 
scheduling  interval  is  defined  to  be  21  bms  (binary  milliseconds). 

The  requested  beams  are  siored  for  use  by  the  Radar  Scheduler  in  four  types  oi 
queues.  The  searcn  and  special  request  type  queues  are  maintained  by  :.he  Searcn 
Management  Process."  The  track  and  missile  type  queues  are  maintained  by  the  Track 
Management  Process.^  The  Radar  Scheduler  gains  access  to  these  queues  through 
pointers  in  the  Priority  Event  List.  The  Priority  Event  List  in  turn  provides  the 
scheduler  with  a  mechanism  for  prioritizing  the  requested  beams  (  see  Table  3). 
Therefore,  an  ordering  of  the  beams  is  developed  in  two  ways.  From  *.ne  queue 
structure  they  are  ordered  in  a  first  come  first  served  fashion.  Second,  the  queues 
themselves  are  ordered  by  association  with  the  Priority  Event  List.  The  queue 
associated  with  the  radar  event  at  the  beginning  of  the  list  has  the  highest  priority  as 
indicated  in  the  table.  Togetner  these  data  structures  provide  the  oasis  of  the  priority 
scheme  used  for  selecting  the  requested  beams. 

When  the  Radar  Scheduler  program  is  loaded  for  execution,  the  Priority  Event 
List  and  the  scheduler's  internal  data  structures  are  automatically  initialized.  Also 
included  in  this  initialization  are  the  data  structures  that  the  scheduler  produces. 

The  scheduling  interval  begins  after  advancing  the  event  counts  and  updating  the 
real  time.  Next  the  external  dwell  buffers  are  swapped  preparing  them  for  the  next  set 
of  dwells  to  be  scheduled.  Once  the  buffers  have  been  swapped,  the  enhancement 
procedure  modifies  the  Priority  Event  List  holding  the  requested  beams. 

The  enhancement  routine  dynamically  enhances  the  priority  of  the  events  in  the 
list  and  in  effect  changes  its  traversal  order.  Changing  the  traversal  order  of  the  events 
increases  the  probability  of  selection  for  those  requested  beam  queues  associated  with 
the  events  at  the  head  of  the  list. 


2, 
.111 

Track  and  missile  queues  are  formed  from  the  Track  Node  data  structure. 


'Search  and  special  request  queues  are  formed  from  the  Search  Node  data 
structure. 
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After  enhancement  and  resynchronization  of  computer  and  radar  times,  the  beam 
selection  process  begins.  During  this  process  beams  are  considered  for  selection  by 
traversing  the  Priority  Event  List  in  its'  current  priority  order.  The  highest  priority 
beam  is  selected  first  and  so  on  until  the  resource  constraints  are  exhausted  for  that 
particular  interval. 

There  are  several  resource  constraints  that  must  be  considered.  There  must  be 
sufficient  radar  resources  available  to  handle  the  requested  beams.  The  elapsed  time  for 
the  scheduling  interval  must  be  less  than  the  allowed  eiapsed  time.  The  total  dwells 
scheduled  must  not  exceed  the  maximum  allowed  during  an  interval.  The  final 
constraint  occurs  by  completely  traversing  the  Priority  Event  List  and  in  effect 
terminating  the  beam  selection  process.  If  these  constraints  are  met,  traversal  of  the 
Priority  Event  List  is  continued. 

If  the  event's  beam  queue  is  not  empty  then  the  beam  queue  is  traversed 
processing  eacn  requested  beam.  First  the  beams  information  is  inserted  into  a  Radar 
Event  Control  Table  node.  Next  supplementary  dwell  processing  occurs  in  preparation 
for  scheduling.  Alter  this  is  accomplished,  the  selected  beams  ire  given  an  array  face 
assignment  and  a  comparison  is  done  between  *he  beam's  transmission  and  the  radar 
doctrines  that  are  in  effect.  Once  this  is  accomplished  the  beams  must  meet  the  final 
selection  criterion  of  satisfying  the  hardware  constraints. 

If  the  hardware  constraints  were  satisfied,  then  the  selected  beam  is  sent  to  the 
external  dwell  buffers,  load  evaluation  occurs,  and  the  node  is  added  to  the  Radar 
Event  Control  Table.  If  the  hardware  constraints  were  not  satisfied,  then  the  node  is 
returned  to  the  pool  of  available  Radar  Event  Control  Table  nodes  for  future  use.  The 
Radar  Scheduler  then  considers  the  next  beam  in  the  event's  request  queue,  and  so  on 
until  the  queue  is  empty. 

When  the  beams  in  the  queue  have  been  considered  the  scheduler  moves  on  to 
the  next  event  in  the  list.  This  continues  until  all  the  events  in  the  Priority  Event  List 
have  been  considered  or  the  resource  constraints  can  no  longer  be  met.  Once  this 
occurs,  the  scheduling  interval  is  completed  and  the  elapsed  time  is  computed. 

If  the  results  of  this  interval  are  requested  by  the  program  operator,  then  the 
appropriate  information  is  dumped  into  a  file  called  "RSOUT.TXT".  Then  the  memory 
is  freed  up  for  the  next  scheduling  interval  by  returning  the  nodes  that  make  up  the 
Radar  Event  Control  Table  to  the  pool  of  available  nodes. 
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The  run-time  Radar  Scheduler  model  does  not  implement  the  following  design 
time  modules:  Resynchronization  (RSM4),  Supplementary  Dwell  Processing  (RSM6), 
Radar  Array  Face  Assignment  (RSM7),  Comply  With  Radar  Doctrine  (RSM8),  and 
the  Radar  Load  Evaluation  (RSM11)  module.  Implementation  of  the  modules  that  are 
not  coded  would  require  knowledge  of  the  required  data  structure  values  to  be 
produced.  Due  to  time  constraints,  the  design  decisions  which  must  be  made  to 
produce  those  values  must  be  deferred  until  the  processes  that  will  use  them  are 
designed  and  implemented.   [Ref.  5:  pp.  46-47] 

C.       EXTERNAL  DATA  STRUCTURES 

The  external  data  structures  are  global  constants,  variables,  and  type  declarations 
which  act  as  interfaces  between  the  Radar  Scheduler  modules  and  the  other  Control 
Group  and  Support  Group  modules.  The  modules  are  referred  to  as  tables  and  are 
numbered  consecutively  from  zero  to  seventy- seven. 

A  Common  Memory  Interface  Matrix.  Table  2.  is  designed  to  be  used  as  an 
index  Into  the  listing  of  the  external  data  structures  located  in  Appendix  D.  The 
applicable  data  structures  for  the  Radar  Scheduler  Module  can  be  found  by  reading 
across  row  "R"  to  locate  the  output  data  structures  and  down  column  "R"  to  locate  the 
input  'lata  structures. 

1.  Data  Structures  Consumed 

These  data  structures  reside  in  common  memory  and  are  declared  by  Library 
Packages  for  use  by  the  Radar  Control  processes  which  read  from  and  write  to  them. 
The  Radar  Scheduler  uses  the  data  structures  in  the  following  tables  to  select  and 
format  dwells  during  a  scheduling  interval. 
a.    Table  0  -  Priority  Event  List 

The  Radar  Event  Priority  List  is  visible  to  the  Radar  Scheduler  (consumer), 
Search  Management  (producer),  and  the  Track  Management  (producer)  procedures 
only.  The  variable  pri_lst  is  a  one  dimensional  array  of  radar  events  which  correspond 
to  the  Radar  Event  Priority  List  depicted  by  Table  3  .  The  array  simulates  a  linked  list 
so  that  priorities  can  be  changed  dynamically  during  execution.  Each  element  in  the 
array  is  a  pointer  corresponding  to  a  unique  Radar  Event.  Each  event  contains  a 
BeamQue  which  is  a  variable  record  that  holds  a  pointer  to  a  queue  of  requested 
beams.  Although  each  queue  is  unique,  they  are  classified  as  either  search,  special 
request,  track,  or  missile  type  queues,  depending  which  Radar  Event  the  beam  queue 
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belongs  to.    The  variable  record  is  designed  to  associate  search  and  special  request 

beams  with  the  search  node  data  structure  found  in  TAB  1. LIB.  The  track  and  missile 

type  beams  are  associated  with  the  track,  node  data   structure  of  TAB2.LIB.   The 

Priority  Event  List  is  the  key  to  the  selection  process.    By  placing  the  beam  queues  in 

the  Priority  Event  List,  the  requested  beams  are  prioritized  by  association  with  their 

respective  radar  events.  The  requested  beam's  priority  is  used  as  the  main  criterion  for 

selection.  Furthermore,  since  the  Priority  Event  List  is  designed  to  act  like  a  linked  list, 

the  traversal  order  can  be  changed  for  each  interval  to  ensure  the  eventual  selection  of 

the  lowest  priority  beams. 

The  constants  and  variables  defined  by  this  data  structure  are  described  as 

follows: 

status  is  a  boolean  flag  which  is  set  to  true  when  the  event  queue  has 
information  in  it. 

eventnm  is  a  string  with  the  event  name  corresponding  to  the  Radar  Event 
Priority  List  (Table'2). 

max  nodes  is  a  variable  representing  the  maximum  number  of  nodes  that  the 
event's  requested  beam  queue  can  hold. 

que  id  is  in  enumeration  type  variable  corresponding  to  one  o[  four  possible 
queue  types,  search  ,  special_request  ,  track  .  or  missile  . 

que_ptr  is  actuallv  a  variable  record  .containing  a  oointer  to  the  first  node  in 
tne "event's  requested  oeam  queue,  [f  the  que_ia  is  a  search  or  special  request 
type  queue  then  the  pointer'  Snode  is  visible,  otherwise  the  pointer  Tnode  is 
visible. 

enhnc  acts  as  a  flag  which  when  set  to  true  indicates  that  the  priority  of  the 
event  can  be  enhanced  bv  the  Radar  Scheduler  when  the  conditions  s'tated  in 
Radar  Scheduler  Module  3  are  met. 

b_pri  is  an  integer  variable  which  holds  a  constant  value  corresponding  to  the 
event's  base  priority.  This  value  is  the  same  as  the  "pri_lst"  array  s  index  value. 

c  pri  is  an  integer  variable  which  corresponds  to  the  event's  current  priority  as 
determined  by  Radar  Scheduler  Module  3. 

ltx  indicates  the  last  time  a  beam  from  this  event  was  selected  by  the  Radar 
Scheduler. 

alhvd_ltx  indicates  the  allowed  time  between  selection  for  this  type  of  event. 

slct_flg  is  a  flag  which  is  set  to  true  if  a  beam  from  this  event  was  selected 
during  the  previous  interval. 

nxt  is  an  integer  variable  used  as  an  index  or  pointer  to  the  next  prioritv  in  the 
pri  1st.  It's  value  can  only  be  changed  during  priority  enhancement.  The  value 
0""acts  as  an  end  of  list  marker  in  the  same  way  that  a  null  pointer  marks  the 
end  of  a  linked  list. 

low_enhnc  is  a  constant  which  stands  for  the  lowest  enhancement  value,  4. 

max_pri  is  a  constant  which  stands  for  maximum  priority  but  is  actually  the 
maximum  number  of  events  in  the  Priority  Event  List  or  the  length  of  the 
prijst  array,  26. 
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b.  Table  1  -  Search  Node 

This  data  structure  acts  as  a  template  for  the  nodes  within  the  search  and 

special   request   beam  queues.     Table    1    also   provides   an   interface   for   the    Radar 

Scheduler  process  and  the  Search  Management  process.  The  fields  contained  in  the 

search  node  record  are  as  follows: 

info.mode  is  the  event  number  identifier.  It  can  have  a  unique  value  between  1 
and  26. 

info.bid  is  a  character  strina  which  acts  as  a  unique  beam  identifier  for  scheduler 
efficiency  analysis. 

info.neam_posit.azim  is  an  integer  variable  describing  the  reauested  beam's 
azimuth  position  in  deck  space  coordinates. 

info.beam_posit.elev  is  m  integer  variable  describing  the  reauested  beams 
elevation  position  in  decis.  space  coordinates. 

info.inst_rge  is  a  variable  which  gives  an  indication  oi  the  range  'o  which  the 
search  oeam  is  to  be  effective. 

lnfo;stc  dara  is  rhe  sensitivity  rime  control  variable.  This  is  used  as  an  indication 
of  howlnucn  power  will  be  allowed  to  oe  used  to  pull  contacts  out  of  clutter. 

inf6.dbct_blnk_gte  holds  the  vaiue  for  tne  radar  doctrine  range  gate. 

info;cltrjblnk_gte  holds  the  value  for  the  radar  clutter  range  gate. 

info.eof  inaic  is  a  flag  vhich  when  set  to  true  indicates  "hat  search  frame  las 
been  completed.  A  search  (fame  consists  of  360  degrees  of  azimuth  ana  '0 
degrees  of  elevation. 

info.req  id  is  used  to  hold  the  identity  of  the  requesting  process  for  special 
requestbeams. 

nxt  is  a  pointer  to  the  next  node  in  this  queue,  which  is  a  linked  list  of  Search 
Nodes. 

c.  Table  2  -  Track  Node 

This  is  a  common  memory  interface  data  structure  between  the  Radar 
Scheduler  process  (consumer)  and  the  Radar  Return  process  (producer)  only.  The  track 
Node  is  a  template  for  the  nodes  within  track  and  missile  beam  queues.  The  data  fields 
declared  in  the  Track  Node  are: 

•  info.mode  is  the  event  number  identifier.  It  can  have  a  unique  value  between  1 
and  26. 

•  info.bid  is  a  character  string  which  acts  as  a  unique  beam  identifier  for  scheduler 
efficiency  analysis. 

•  info.ptrk  is  a  pointer  to  the  Track  File  which  this  node  is  requesting  a  beam 
for.  The  Track  Tile  data  structure  is  located  in  Table  7. 

•  nxt  is  a  pointer  to  the  next  Track  Node  in  this  queue,  which  is  a  linked  list  of 
Track  Nodes. 
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d.    Table  3  -  I  to  R 

Table  3  is  a  common  memory  interface  data  structure  for  the  Radar 
Scheduler  (consumer)  and  Radar  Return  (producer)  processes.  The  data  structure  the 
following  SPY-1  radar  status  variables: 

•  resynch_time   is   the   amount    of  time   that    the   Radar   Scheduler   is    out    of 
synchronization  with  the  SPY-1  radar  expressed  in  milliseconds. 

•  loop_con  is  an  inteser  variable  used  to  tell  the  Radar  Scheduler  how  far  ahead 
or  behind  in  the  radar  control  loop  the  Radar  Control  Program  is. 


♦  xmsn_status  is  a  boolean  variable  indicating  the  transmission  status  o(  the 
previous  interval's  scheduled  beams. 

e.    Table  4  -  A  to  R 

Table   4  is   a   common   interface   data    structure    between   the    Detection 

Processing  Process  (consumer),  Radar  Scheduler  Process  (consumer),  and  the  Switch 

Action  and  Display  Process  (producer).  The  data  structure  contains  RCS  commands  to 

aid  in  the  formating  of  iie  radar  dwell  buffer.    The  data  fields  are  as  follows: 

«  power  fig  is  a  iooiean  variable  that  represents  the  status  of  the  radar  power. 
When  'powerjlg"  is  set  to  true,  the  power  is  to  high,  and  when  it  is  set  to  false; 
t.ne  power  is  to  low. 

♦  rad_p>vr  notion  is  a  boolean  variable  that  reDresents  the  status  of  the  radar 
power  oTbtion.  When  set  co  true  the  power  oduoii  ls  on.  ana  when  set  to  false 
the  power  option  is  off. 

♦  'ad  inhibt  regions  is  i  ive  element  array  of  records  containing  start  and  stop 
bearings  for  "one  or'  live  possible  radiation  inhibition  regions  definable  by 
doctrine. 


rad_inhibt_regions(  ).start_bn.g  is  the  bearing  start  indicator. 

rad_inhibt_regions(  ).stop_bng  is  the  bearing  stop  indicator. 

op  doct.mtrks  is  the  maximum  number  of  tracks  to  be  initialized  in  the  Track 
File.  This  value  is  used  to  aid  in  testing  the  Radar  Scheduler  Module. 

•  op  doct.mintvls  is  the  maximum  number  of  scheduling  intervals  to  be  run  on  a 
tesl  of  the  Radar  Scheduler  Model. 

•  op_doct.dply_rect  is  an  integer  variable  used  to  define  the  interval  display  delay 
period. 

/.    Table  5  -  Command  and  Decision  User  Services  Interface 

Table  5  is  visible  to  the  Radar  Scheduler  Process  (consumer)  and  the 

Command  and  Decision  User  Services  Process  (producer).  The  interface  contains  one 

variable  to  communicate  the  transmission   status: 

•  rdr_silence  is  a  boolean  variable  which  when  set  to  true,  informs  the  Radar 
Scheduler  that  radar  silence  is  in  effect. 
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g.    Table  6  -  Beam  Stabilization  Interface 

Table  6  is  a  common  memory  interface  between  the  Radar  Scheduler 
Process  (consumer)  and  the  Beam  Stabilization  Process  (producer).  The  data  structure 
contains  information  concerning  array  face  limits  and  the  ship's  motion  matrix.  The 
data  fields  are  as  follows: 

•  face  antenna  limits  is  a  four  element  array  of  records  containing  the  left  and 
righf  for  each"  of  the  four  phased  array  antenna  faces. 

•  face_antenna  limitsC  ). limit  left  indicates  the  left  most  bearing  limit  to  an 
accuracv  of  til  degrees  for  the  ohased  arrav  antenna  face  indicated  bv  the  arrav 
index.  The  limits  "are  converted  into  stable  space  bearings  from  deck,  space 
bearings  by  the  gyro  converters. 

•  face  antenna_limits(  ). right  limit  is  the  same  as  above  onlv  pertaining  to  the 
right"  most  limit. 

•  ships_motion_matrLx.x_ship_dot  is  the  value  of  the  ship's  velocity  in  the  x  deck 
direction. 

•  ships  motion  matrix. v  ship_dot  is  the  value  of  the  shio's  velocity  in  the  v  deck. 
direction. 

•  snips_motion_matrix.roll  is  the  amount  oi'  roll  the  ship  is  experiencing. 

•  ships_motion_matrix. pitch  is  the  amount  of  pitch  the  ship  is  experiencing. 

•  ships_motion_matrix.yaw  is  the  amount  of  yaw  the  ship  is  experiencing. 

•  azimJ.imit_siope  is  the  limiting  value  of  the  rise  in  elevation  for  a  given  azimuth. 

h.    Table  7  -  Track  File 

Table  7  is  a  common  memory  interface  between  the  Radar  Scheduler 
Process  (consumer/producer),  the  Detection  Processing  Process  (producer),  Track. 
Processing  Process  (producer/consumer),  and  the  Track  Management  Process 
(consumer).  The  Track  File  acts  as  a  memory  map  which  allows  dynamic  allocation  of 
memory  for  tracks  as  they  are  acquired.  The  files  are  arranged  in  a  linked  list  of  track 
file  nodes.  The  track  file  nodes  contain  two  major  hierarchy  levels  beam  data  and  track 
data.  These  data  fields  are  defined  as  follows: 

•  beam  data. mode  is  an  integer  between  1  and  26  which  corresponds  to  the 
identity  of  the  radar  event  for  this  track. 

•  beam  data.bid  is  a  character  string  which  uniquely  identifies  the  requested  beam 
for  this  track. 

•  beam_data.priority  is  an  integer  value  corresponding  to  the  relative  priority  of 
this  track  compared  to  the  other  tracks  in  this  Track  File. 

•  beam_data.posit.x  is  the  rectangular  X  coordinate  of  the  track  position  as  found 
when  it  was  last  illuminated  by  the  radar. 

•  beam_data.posit.y  is  the  rectangular  Y  coordinate  of  the  track  position  as  found 
when  it  was  last  illuminated  by  the  radar. 

•  beam  data.posit.z  is  the  rectangular  Z  coordinate  (elevation)  of  the  track 
position  as  found  when  it  was  last  illuminated  by  the  radar. 
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beam_data.posit.slnt_rge  is  the  straight  line  range  to  the  track's  last  position. 

beam_data.posit.x_dot  is  the  track's  velocity  in  the  X  direction. 

beam_data.posit.y_dot  is  the  track's  velocity  in  the  Y  direction. 

beam_data.posit.z_dot  is  the  track's  velocity  in  the  z  direction. 

beam_data.posit.rge_dot  is  the  tracks  relative  change  in  straight  line  range. 

beam  data.trk  xsitn  flag  is  a  boolean  variable  which  when  set  to  true  indicates 
that  fhe  trackTias  alrack  historyless  than  or  equal  to  four  detections. 

beam  data.ctl_grp_trk_num  is  a  number  which  corresoonds  to  the  track's  Radar 
Control  Group  track  number. 

beam_data.ctsl  is  a  number  used  to  historically  record  the  track. 

beam  data.xgte  bin  num  is  a  number  which  corresponds  to  the  track's  location 
in  the" cross-gating  matrix. 

beam_data.pred  azim  is  a  bearing  value  correspondine  to  where  the  track  is 
predicted  to  be~bv  the  Radar  Scheduler  upon  scheduling  a  track  dwell  on  this 
track. 

beam_data.pred_elev  is  the  predicted  elevation  of  the  crack. 

beam  data.Iow  eiev  nrk._flg  is  set  to  true  when  the  track's  elevation  is  below  a 
preset  altnuderThe~actuai  settings  are  classified. 

beam  data.iog_ampld  est  is  an  estimate  of  the  return  sienal  strength  of  the  radar 
echo  "oouncea  off  this  track. 

beam_data.xmit_req_flg  is  a  boolean  variable  which  when  sec  ko  true  indicates 
TraclT  Processing  is  requesting  a  dwell  be  Transmitted  for  this  track. 

beam_data.sim  tgt_flg  is  a  boolean  variable  which  is  set  to  true  when  the  track 
is  a  simulated  Target. 

nxt_trk  is  a  pointer  to  the  next  track  node  in  the  Track  File.  The  data  fields 
associated  with  this  pointer  are  defined  by  the  declarations  in  Table  2. 

I.    Table  8  -  frequency  Management  Interface 

Table  8  is  used  by  the  Radar  Scheduler  Process  (consumer)  to  complete 

formatting    of  selected   radar   dwells.    The    data    structure   contains    frequency   and 

waveform  information  in  the  following  fields: 

waveform  is  an  array  from  1  to  "max_dwells"  of  records  containing  waveform 
information. 

\vaveform(  ).freq_chnl  is  the  channel  frequency  to  be  used  by  this  beam. 

>vaveform(  ).freq_band  is  the  frequency  band  to  be  used  by  this  beam. 

>vaveform(  ). phase  l_code  is  the  frequency  phase  code  used  for  transmitting  this 
beam. 

>vaveform(  ).phase2_code  is  the  second  half  of  the  frequency  phase  code  used  for 
transmitting  this  beam. 

>vaveform(  ).mti.pri  is  the  PRI  code  used  when  the  beam  is  an  MTI  beam. 

waveform(  ).mti.d\vl_length  is  the  length  or  duration  of  the  dwell  in 
microseconds  if  the  beam  is  a  MTI  beam. 
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•  >vaveform(  ).msle.uplnk  freq  is  the  frequency  used  to  communicate  with  own 
ship's  S\T-2  missile,  if  the  beam  is  a  missile  communication  beam. 

•  \vaveform(   ).msle.d>vn  freq   is   the   frequency  used   by   the  missile   to   transmit 
information  back  to  tITe  ship,  when  the  beam  is  a  missile  communication  beam. 

•  >vaveform(  ).inhib_freq_chnl   are  the  frequency  channels  which  are  prohibited  to 
this  beam. 

j.    Table  9  -  L  to  R 

Table  9  is  the  common  memory  interface  between  the  Radar  Scheduler 
Process  (consumer)  and  the  Load  Evaluation  Process  (producer).  This  data  structure  is 
used  by  the  Radar  Scheduler  Process  to  format  track  dwells  and  contains  only  one  data 
field: 

•  trk._um   :tr  reset   is  a  boolean   variable  which  when  set   to   true   informs  the 
Raaar  Scheduler  Process  to  zero  out  its  track  time  counter. 

k.    Table  10  -  Missile  Downlink  Interface 

Table  10  is  the  common  memory  data  structure  between  the  Radar 
Scheduler  Process  (consumer)  ana  the  Missile  Communications  Process  (producer). 
Since  che  actual  data  fields  are  classified,  the  downlink  message  is  arbitrarily  separated 

into  eight  parts  as  follows: 

mssi  dwnink  is  an  array  form  one  to   'num_mssl_msgs"  of  records  :ontaining 
missile  messages. 

mssljiwnink<  ).prt_one  ;s  an  integer  variable. 

mssl_dwnlnk(  ).prt_two  is  an  integer  variable. 
mssl_dwnlnk(  ).prt_three  is  an  integer  variable. 
mssl_dwnlnk(  ).prt_four  is  an  integer  variable. 
mssl_dwnlnk(  ).prt_five  is  an  integer  variable. 
mssl_d>vnlnk(  ).prt_six  is  an  integer  variable. 
mssl_d>vnlnk(  ).prt_seven  is  an  integer  variable. 
mssl_d\vnlnk(  ).prt_eight  is  an  integer  variable. 
2.  Data  Structures  Produced 

These  data  structures  are  located  in  common  memory.  They  are  used  by  the 
Radar  Scheduler  Process  (producer)  and  those  processes  which  are  consumers  of  the 
data. 

a.    Table  11  -  Search  Management  Interface 

Table  1 1  is  the  common  memory  data  structure  interface  between  the 
Radar  Scheduler  Process  (producer)  and  the  Search  Management  Process  (consumer). 
The  data  structure  is  used  by  the  Search  Management  Process  to  distinguish  which 
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search  queues  require  filling.  The  Radar  Scheduler  sets  the  flags  when  it  has  used  a  set 
number  of  search  request  beams.   The  flags  are  defined  below: 

•  hs_que_replen  is  a  boolean  variable  which  when  set  to  true  indicates  that  the 
horizon  search  queue  needs  to  be  replenished. 

•  ahs_que  replen  is  a  boolean  variable  which  when  set  to  true  indicates  that  the 
above  horizon  search  queue  needs  to  be  replenished. 

b.  Table  17  -  Track  Management  Interface 

Table  17  is  the  common  memory  data  structure  between  the  Radar 
Scheduler  Process  (producer)  and  the  Track.  Management  Process  t consumer).  The 
Radar  Scheduler  Process  uses  the  data  structure  to  hold  the  scheduled  Track,  dwells 
seiectea  for  transmission.  The  Track  Management  Process  uses  the  data  structure  to 
asses  its  efficiency  in  prioritizing  previously  requested  tracks.  The  data  fields  are 
defined  as: 

•  sched_trk_beamjist  is  an  array  from  one  to  "max_dwells"  of  records. 

•  sched  trk  beam  list(     .mode  ;d  ;s  a  integer  variable  used  to  identify  the  ^adar 
event~associatecfwitn  the  scheduled  track. 

»      sched  trk  beam  !ist(  ).trk  file    ium  is  the  uniaue  track  number  of  the  scheduled 
track." 

•  sched_trk_beam_iisT<    .priority. 

c.  Taoie  20  -  Track  Processing  Inter/ace 

Taoic   20  is  a  common  memory  interface  used  by  the   Radar  Scheduler 

Process  (producer)  and  the  Track  Management  Process  (consumer).  The  data  structure 

contains  information  on  each  of  the  scheduled  dwells  for  one  scheduling  interval.  As 

dwells  are  formatted  for  transmission,  the   Radar  Scheduler  Process  transmits   the 

information.  The  data  fields  are  defined  as  follows: 

stble_spc_pos  is  an  arrav  from  one  to  "max_dwells"  of  records  containing  stable 
space  position  information. 

stble_spc_pos(  ).azim  is  the  bearing  of  the  scheduled  dwell  in  tenths  of  degrees. 

stble_spc_pos(  ).elev  is  the  elevation  of  the  scheduled  dwell  in  tenths  of  degrees. 

stble_spc_pos(  ).x_posit  is  the  rectangular  X  coordinate  of  the  scheduled  dwell. 

stble_spc_pos(  ).y_posit  is  the  rectangular  Y  coordinate  of  the  scheduled  dwell. 

stble_spc_pos(  ).z_posit  is  the  rectangular  Z  coordinate  of  the  scheduled  dwell. 

sched  xmsn_time  is  the   scheduled  transmission  time   in  milliseconds  for  the 
scheduled  dwell. 

d.  Table  32  -  Radar  Output  Interface 

Table  32  is  the  common  memory  interface  between  the  Radar  Scheduler 
Process  (producer)  and  the  Radar  Output  Process  (consumer).  It  acts  as  a  buffer  for 
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the  formatted  dwells,  and  supplies  information  to  the  Radar  Output  Process  to  aid  in 
completing  the  channel  I/O  control  buffer.   The  data  structures  in  Table  32  are  defined 


as  follows: 


ptr_r  to_o  is  a  two  element  array  of  pointers  used  to  access  two  linked  lists  of 
record's  containing  dwell  data. 

ptr_r_to_o(  ).d>vl_data.mode  is  the  major  transmission  mode  used  by  this  dwell. 

ptr_r_to_o(  ).d\vl_data.face  is  the  antenna  face  assigned  to  this  dwell. 

ptr_r_to_o(  ).dwl_data.sub_mode  is  a  two  element  array  of  integers  which  are  the 
frequency  sub-modes  assigned  to  this  dwell. 

ptr_r  to_o(    "t.dwi  data.dwHdx    is    the    dwell    index    number    for    the    current 
scheduling  interval. 

Str_r_to_o(   ).d\vl_data.bearnpurpose   is   an   integer  which   corresponds   to    the 
earn  s  mode  value  which  indicates  what  purpose" the  dwell  was  scheduled  for. 

ptr_r  to  o(  ).dwl  data.dwl  start  idx  is  a  32  bit  number  which  is  the  transmission 
time  Tor  the  dwell  to  an  accuracy  which  is  classified. 

ptr_r_to_o(   ).dvvi_data.doct_unbink  gates  data  has  been  read  from  the  Search 
Management  provided  data. 

ptr  r  to  o(      ».dwl  data.clutter  unblnk  gates     data     is     the     same     form     as 
doer  7in51nk  sates." 
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ptr_r_to_o(  ).iink  is  a  pointer  to  the  next  dwell  data  record  in  the  linked  list. 

e.    Table  40  -  Output  Control  Channel  Buffer 

Table  40  is  a  common  memory  interface  between  the  Radar  Scheduler 

Process  (producer),  the  Radar  Output  Process  (producer),  the  Radar  Control  Program, 

and  the  Radar  Channel  Control  Program  (consumer).  The  Radar  Scheduler  Process  has 

responsibility  for  filling  only  a  small  portion  of  the  data  fields  which  are  defined  below: 

occb_ptr  is   a   two   element   array   of  pointers   to   two   linked  lists   of  records 
containing  Output  Channel  Control  Buffer  information. 

occb_ptr(  ).oa.cntrl  \vord.rdr_xmsn_on  is  a  boolean  variable  which  when  set  to 
true  indicates  that  Hie  dwell  is  to  be  transmitted. 

occb_ptr(  ).om.face  is  the  antenna  face  assigned  to  this  dwell. 

occb  ptr(  ).oh.pril_mti  is  the  MTI  PRI  code  used  by  the  dwell  when  it  is  an 
MTTawell. 

occb_ptr(  ).oh.pri2_mti  is  the  second  half  of  the  PRI  code. 

occb_ptr(    ).ot    is    a    twelve    element    array    of    records    emulating    missile 
communications  links. 

occb_ptr(  ).ot(  ).otmsb  emulates  a  missile  communication  link  when  the  dwell  is 
a  missile  dwell. 

occb_ptr(  ).ot(  ).otlsb  also  emulates  a  missile  communications  link. 

occb_ptr(  ).ol.xmit_freq  is  the  transmission  frequency  used  by  this  dwell. 

occb_ptr(  ).ol.rcm_freq  is  the  receiver  frequency  used  to  receive  the  return  dwell 
signal. 
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occb_ptr(  ).oj.subchnl_freq_group  is  the  group  of  sub-channel  frequencies  used  to 
transmit  this  dwell. 

occb_ptr( ). o_f.ph.se  l_code  is  the  first  part  of  the  dwell  frequency  phase  codes. 

occb_ptr(  ).og.fdbkl  is  the  first  part  of  the  dwell  feedback  phase  codes. 

occb_ptr(  ).oa.cntrl  word.freq_group_slct  is  a  boolean  flag  which  when  set  to 
true  indicates  the  selected  frequency  group  for  this  dwell. 

occb__ptr(  ).oi.d"\v  M_start_time  is  the  start  time  for  the  dwell  in  microseconds. 

occb  ptr(  ).ob.detectl_thrsld  holds  the  value  of  an  expected  detection  range  for  a 
track"  type  dwell. 

occb  ptn  ).ob.detect2  thrsid  holds  the  value  of  an  expected  detection  range  for  a 
tracE"  type  dwell. 

occb_ptr(  ).ob. detect3  thrsid  holds  the  value  of  an  expected  detection  range  for  a 
tracK.  type  dwell. 

occb_ptr(  ).oe.truncl_thrsld  is  a  truncation  signal  level  threshold  value  to  assist 
in  detecting  targets.  ~ 

occb  ptr(  ).oe.trunc2  thrsid  is  a  truncation  sisnal  level  threshold  value  to  assist 
in  detecting  targets.  ~ 

occb_ptr(  ).oq.eiev_sector  is  the  sector  elevation  limits  for  this  dwell. 

occb_ptr<  ).os.dpiy_azim  is  the  bearing  the  dwell  is  to  be  transmitted  on. 

occb  ptn   J.o  r.aplv_eiev  is  the  elevation  this  dwell  is  to  be  transmitted  on  in 
degrees.  ' 

occbjptr(  ).os.video_extnt  is  the  signal  level  expected  from  this  dwell. 

occb_ptr(  ).trk_gate_strt  is  the  starting  range  for  gating  a  track  dwell. 

occb  ptr(  ).link  is  a  pointer  to  the  next  Output  Channel  Control  Buffer  node 
available. 


D.       INTERNAL  DATA  STRUCTURES 

All  data  structures  that  are  internal  to  the  Radar  Scheduler  Process  and  that 

must  be  shared  by  subordinate  Radar  Scheduler  modules  are  located  in  the  package 

specification  of  RSMO.   The  data  structures  are  defined  as  follows: 

rdrint  is  a  constant  that  represents  the  maximum  time  which  can  be  spent  in  the 
Beam  Selection  Module. 

srch_que  is  a  constant  used  to  represent  the  event  type  Search. 

sr_que  is  a  constant  used  to  represent  the  event  type  Special  Request. 

trk_que  is  a  constant  used  to  represent  the  event  type  Track. 

mssl_que  is  a  constant  used  to  represent  the  event  type  Missile. 

srch  dwls  is  a  constant  equal  to  the  maximum  number  of  Search  events  that  can 
be  scheduled  in  one  interval. 

srjhvls  is  a  constant  equal  to  the  maximum  number  of  Special  Request  events 
that  can  be  scheduled  in  one  interval. 
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trk_cbvls  is  a  constant  equal  to  the  maximum  number  of  Track  events  that  can 
be  scheduled  in  one  interval. 

mssl  dwls  is  a  constant  equal  to  the  maximum  number  of  Missile  events  that 
can  b"e  scheduled  in  one  interval. 

rdr_rsrcs  is  a  constant  which  represents  the  percentage  of  radar  resources  which 
can  be  used  in  scheduling  beams  for  an  interval. 

ppl  is  an  integer  variable  used  as  an  index  for  traversing  the  priority  list. 

intvl  num  is  an  integer  variable  used  to  represent  the  number  of  intervals  that 
have~been  executed. 

The  next  data  structure  contained  in  RSMO  is  the  Radar  Event  Control  Table. 

This  is  [he  primary  data  structure  used  by  the  Radar  Scheduler  to  schedule  a  mix  of 

radar  events  for  one  scheduling  interval.  The  Radar  Event  Control  Tabie  is  a  linked  list 

of  records.    The  records  which  act  as  nodes  contain  the  following  fields: 

•  srch  dvvl  is  a  pointer  to  a  Search  Node  data  structure  described  in  external 
Table  I. 

■       trk_dwl  is  a  pointer  to  a  TracK  Node  data  structure  described  in  external  Table 

•  ocb  data  ;s  a  record  containing  [he  data  to  be  transmitted  to  [he  external  dwell 
buffers.  Explanations  for  [he  data  fields  in  this  record  can  be  found  in  Sections 
IV.C.2.Q  arid  e. 

•  leamid  is  a  a  character  string  used  for  resting  the  logic  of  che  Radar  Scheduler 
algorithm. 

•  dru  is  an  integer  also  used  for  resting  the  logic  of  the  Radar  Scheduler 
aigorunm. 

•  nxt  event  is  a  pointer  which  acts  as  a  link  to  the  next  Radar  Control  Table 
node  in  the  linked  list. 

•  rect  is  a  pointer  to  the  head  of  the  Radar  Control  Table's  linked  list  data 
structure. 


sp  is  a  pointer  to  the  Search  Node  data  structure  described  in  Table  1. 

tp  is  a  pointer  to  the  Track  Node  data  structure  described  in  Table  2. 

rect_ptr  is  a  pointer  to  the  head  of  the  linked  list  which  makes  up  the  Radar 
Event  Control  Table. 

pool_ptr  is  a  pointer  to  Radar  Event  Control  Table  record. 

buff_ptr  is  a  pointer  to  a  the  data  structure  described  in  Table  40. 

cm_ptr  is  a  pointer  to  the  data  structure  described  in  Table  32. 


E.       RADAR  SCHEDULER  MODULE  DESCRIPTIONS 

The  modules  described  in  this  section  are  subordinate  to  the  Radar  Scheduler 
process.  A  functional  description  of  each  of  the  modules,  and  any  subroutines 
subordinate  to  them  is  given  below. 
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1.  Initialization 

The  function  of  the  initialization  module  is  to  create  and  initialize  any  data 
structures,  local  to  the  Radar  Scheduler  process,  that  must  be  shared  between  the 
Radar  Scheduler  modules.  The  creation  of  these  data  structures  is  necessary  only  for 
access  type  data  structures  which  form  linked  lists.  Allocation  of  memory  for  these  data 
structures  prior  to  the  execution  of  the  Radar  Scheduler  process  serves  to  increase  the 
efficiency  of  the  main  scheduling  loop  by  eliminating  the  need  to  allocate  memory  for 
each  new  node  during  scheduling.  This  module  is  executed  oniy  one  time,  when  the 
Radar  Scheduler  process  is  loaded  for  execution. 

The  decision  to  piace  these  variables  in  a  separate  module  instead  of  the 
package  specification  for  the  Radar  Scheduler  process  is  based  on  the  principle  of 
information  hiding.  Since  these  variables  need  to  be  shared  by  other  Radar  Scheduler 
modules  they  must  be  in  a  package  specification.  If  they  were  placed  in  the  Radar 
Scheduler's  package  specification,  then  modules  other  than  Radar  Scheduler  modules 
wouid  be  able  to  access  tnem. 

The  Initialization  mocmie  does  not  consume  any  common  memory  interface 
data  structures.  It  does  produce  the  initial  nool  of  Output  Channel  Control  Buffer 
nodes  and  a  pool  of  Raaar  Event  Control  Table  uodes. 

The  following  data  structures  are  declared  in  module  specification  and  are 

local  to  the  Radar  Scheduler  process: 

rdrinit  is  a  constant  representing  the  maximum  amount  of  time  which  can  be 
spent  in  the  beam  selection  mode. 

srch_que  is  a  constant  assigned  to  the  event  type  search. 

trk_que  is  a  constant  assigned  to  the  event  type  track. 

sr_que  is  a  constant  assigned  to  the  event  type  special  request. 

mssl_que  is  a  constant  assigned  to  the  event  type  missile. 

srch  dwls  is  a  constant  representing  the  maximum  number  of  search  events  that 
can  "Be  scheduled  in  one  interval. 

trk_dwls  is  a  constant  representing  the  maximum  number  of  track  events  that 
can  be  scheduled  in  one  interval. 

sr  dwls  is  a   constant  representing  the  maximum  number  of  special  request 
events  that  can  be  scheduled  in  one  interval. 

mssl  dwls  is  a  constant  representing  the  maximum  number  of  missile  events  that 
can  5e  scheduled   in  one  interval. 

srch_pcnt  is  a  constant  representing  the  percentage  of  radar  resources  allotted 
to  each  search  dwell. 

trk  pent  is  a  constant  representing  the  percentage  of  radar  resources  allotted  to 
each  track  dwell. 
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sr_pcnt  is  a  constant  representing  the  percentage  of  radar  resources  allotted  to 
each  special  request  dwell. 

mssl_pcnt  is  a  constant  representing  the  percentage  of  radar  resources  allotted 
to  each  missile  dwell. 

The  following  data  structures  are  used  to  control  program  execution: 

ppl  is  an  index  used  to  control  traversal  of  the  priority  event  list. 

intvl_num  is  used  to  keep  track  of  the  number  of  intervals  that  have  been 
executed. 

sp  is  a  working  pointer  for  traversing  a  linked  list  of  search  nodes. 

tp  is  a  working  pointer  for  traversing  a  linked  list  of  track  nodes. 

r  is  a  working  poinier  for  traversing  the  Radar  Event  Control  Table. 

rect  ptr  is  a  pointer  which  always  identifies  the  first  node  in  the  Radar  Event 
Control  Table. 

pool  ptr  is  a  pointer  which  alwavs  identifies  the   first  node  in  the  pool   of 
available  Radar  Event  Control  Table  nodes. 

buff_ptr  aiways  points  :o  the  current  Channel  I,  O  Control  node. 

cm_pcr  always  points  to  the  current  Radar  Output  node. 

The  Radar   Event  Control  Table  is  the  primary  data  structure  used  by  the 

Radar  Scheduler  process  to  schedule  the  mix  of  radar  events  for  each  interval.  This 

data  structure  contains  live  major  fields: 

irch  cbvl  :.s  a  mirror  imaee  of  the  search  node  data  structure  (see  Section  Ci.d 
of  this  cnapterj. 

trk  dwl  is  a  mirror  image  of  the  track  node  data  structure  (see  Section  C.l.b  of 
this~chapter). 

ocb  data  contains  the  information  that  is  transmitted  to  the  external  dwell 
buffers.  An  explanation  of 
C.2.d  and  e  of  this  chapter. 


buffers.  An  explanation  of  the  data  fields  in  this  record  is  is  given  in  Sections 
of  tr ' 


beamid  corresponds  to  the  beam  identifier  used  bv  the  srch_d\vl  or  trk_dwl  "bid" 
data  field  and  is  used  for  testing  the  logic  of  the  Radar  Scheduler  algorithm. 

dru  holds  the  total  percentage  of  radar  resources  consumed  after  the  selection  of 
the  current  beam. 

nxt_event  is  a  link  to  the  next  node  in  the  linked  list  that  makes  up  the  Radar 
Event  Control  Table. 

There  are  no  data  structures  locally  declared  within  this  module  body.  The 
procedures  make_pool  and  ex_buff_create  are  declared  local  to  the  module  body  and 
are  used  for  the  initialization  process.  An  algorithmic  description  of  the  Initialization 
module  is  given  in  Figure  4.2  . 

a.   Make  Pool 

The  procedure  Make  Pool  is  derived  from  the  PL/I-80  version  of  RSM1A. 
This   procedure  is  declared  within  the   body  of  the   Initialization  module  described 
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Begin  Radar  Scheduler  Initialization; 

Create  a  pool  of  Output  Channel  Control  Buffer  nodes; 

Create  a  pool  of  Radar  Output  Interface  nodes; 

Create  a  pool  of  Radar  Event  Control  Table  nodes; 

Initialize  working  pointers  for  Radar  Scheduler; 
End  Radar  Scheduler  Initialization; 


Figure  4.2     Initialization  Module  Algorithm. 

above.  The  purpose  of  this  procedure  is  to  make  a  pool  of  Radar  Event  Control  Table 
nodes. 

The  procedure  declares  two  local  pointers,  "p"  and  "q"  for  creating  a  linked 
list  of  Radar  Event  Control  Table  nodes.  The  variable  numb_nodes  stands  for  the 
number  of  nodes  to  be  created. 

b.    Create  Dwell  Suffer  Pools 

The  procedure  Create  Dwell  Buffer  Pools  is  derived  from  the  PL-  [-80 
version  of  RSM1B.  The  task  of  this  procedure  is  to  create  two  circular  linked  lists  for 
the  Output  Channel  Control  Buffer  and  two  circular  linked  lists  for  the  Radar  Output 
Interface  nodes. 

The  procedure  declares  the  following  working  pointers  locally  for  the 
purpose  of  creating  the  circularly  linked  lists: 

•  pi  and  ql  are  Output  Channel  Control  Buffer  pointers. 

•  p2  and  q2  are  Radar  Output  Interface  pointers. 

The  following  data  structures  are  used  for  execution  control  flow  within  the 
procedure: 

•  length  is  the  length  of  the  circular  linked  lists  being  created. 

•  ctr  is  a  variable  used  to  keep  track  of  the  number  of  nodes  being  created. 

•  i  is  an  index  to  control  the  number  of  circular  linked  lists  being  created. 
2.  Swap  Dwell  Buffers 

Functionally,  the  Swap  module  manages  the  Radar  Scheduler's  access  to  the 
two  external  dwell  buffers  described  above.  The  Swap  module  must  insure  that  a 
minimum  number  of  available  nodes  are  present  in  the  pool  for  consumption  by  the 
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Radar  Scheduler  during  each  scheduling  interval.  The  Swap  module  is  called  from  the 
beginning  of  the  main  control  loop  in  the  Radar  Scheduler  process. 

The  Swap  module  consumes  the  global  pointer  variables  to  the  common 
memory  interface  pools  of  Output  Channel  Control  Buffer  and  Radar  Output  nodes. 
This  module  does  not  produce  any  common  memory  interface  data  structures.  The 
algorithm  for  this  procedure  is  given  in  Figure  4.3 

The  input;  output  parameters  are  the  only  data  structures  declared  locally  and 
are  Dassed  by  reference.  These  data  structures  are: 

•  buff  is  a  pointer  to  the  Cutout  Channel  Control  Suffer. 

•  cm   is  a  pointer  to  the  common  memory  interface  Radar  Output  buffer. 

•  index  is  the  index  to  the  current  buffers. 


Begin  Swap  Dwell  Buffers: 
If  the  index  is  two  then 
rhe  index  gets  one: 
else 

the  index  gets  two; 
enu  if; 

change  dwell  buffers; 
End  Swap  Dwell  Buffers; 


Figure  4.3     Swap  Dwell  Buffers  Algorithm. 

3.  Radar  Event  Priority  Enhancement 

The  function  of  this  module  is  to  ensure  that  the  mix  of  radar  events  being 
considered  for  selection  is  optimized  by  their  respective  priorities  in  the  Radar  Event 
Priority  List.  The  design  is  based  on  Digital  Equipment's  VMS  Operating  System 
Priority  Enhancement  Algorithm.  Radar  events  having  base  priorities  lower  than  the 
enhancement  value  have  the  capacity  for  dynamic  prioritization.  The  procedure 
examines  each  event  to  see  if  its  priority  can  be  enhanced.  If  the  event's  priority  needs 
to  be  enhanced,  its  priority  value  is  increased.  Execution  of  this  module  takes  place 
prior  to  the  Beam  selection  and  Synchronization.  When  executed,  the  module 
produces  a  reprioritized  Radar  Event  Priority  List.    [Ref.  5:  p.  76] 
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Begin  Priority  Enhancement; 

Reset  the  last  time  executed  for  all  radar  events; 

Traverse  the  enhanceable  portion  of  the  priority  list; 

If  the  event  is  enhanceable  and  its  queue  is  not 
empty  then 

If  the  time  between  scheduling  of  the  event  is 
greater  than  the  ailowed  time  "then 

[fthe  event's  current  priority  is  above 

the  standard  enhancement  value  out  beiow 

:ne  lowest  enhancement  value  then 

increment  the  event  s  priority  by  i; 

Else 

Increment  the  event's  priority  by  4  but 
not  above  the  low  enhancement  value; 

End  Enhance: 

Reorder  the  priority  event  list; 

End  Last  time  executed: 

End  Traverse  the  priority  list; 

End  Priority  Enhancement; 


Figure  4.4    Priority  Enhancement  Algorithm. 

The  enhancement  module  does  not  consume  any  common  memory  interface 
data  structures.  The  input  parameter  to  this  procedure  is  the  variable  elapsed_time 
which  is  passed  by  value  from  the  Radar  Scheduler  process.  The  parameter 
elapsed_time  is  used  to  update  the  Radar  Event  Priority  List  ltx  data  field.  The 
algorithm  for  the  Enhancement  module  is  presented  in  Figure  4.4 

This  module  uses  the  procedure  ripl  to  remove  and  insert  a  node  from  its 
present  position  in  the  priority  list  to  its  new  position  in  the  list.  The  procedure  is 
declared  locally  in  the  Enhancement  modules  body. 

a.   Remove  and  Insert 

The  Remove  and  Insert  procedure  is  part  of  the  Enhancement  module. 
The  procedure  removes  a  node  from  its  current  position  in  the  priority  list,  inserts  the 
node  at  its  new  priority  and  then  resets   the  current  priority  values  for  the  other  events. 
The  following  data  structures  are  declared  locally: 
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curnt    is  an  input  parameter  passed  by  value  representing  the  event's  current 
lis 


priority  in  the  list. 

new_p    is  an  int 

priority  in  the  list 


ne>v_P    is  a,n  }PPut:  parameter  passed  by  value  representing  the  event's  new 
'st. 


•  p   is  an  index  used  to  traverse  the  priority  list. 

•  b4  is  a  variable  that  holds  the  last  value  of  the  index  "p". 


•      tempi  and  temp2  are  temporary  storage  variables  for  the  indexes. 
4.  Radar  and  Computer  Synchronization 

The  function  of  this  module  is  to  ensure  that  the  Radar  Control  Group  time  is 
synchronized  co  the  radar  time.  The  scheduler  waits  for  a  clocK  update  from  the  radar. 
According  to  AEGIS  performance  specifications,  the  scheduler  must  schedule  dummy 
dwells,  if  the  update  is  greater  than  two  seconds.  The  Radar  Scheduler  design  calls  for 
the  process  to  be  "blocked"  until  synchronization  has  been  accomplished.  The 
scheduler  is  made  "ready'  upon  synchronization  of  clocks  and  Track  File  time  updates. 
The  Radar  Scheduler  must  aier:  the  RSC  (or  in  our  case  the  Switch  Action  and 
Dispiav  process)  to  the  pending  update.  This  requirement  is  not  implemented  in  this 
version  of  the  scheduler  modei.  For  :iock  updates  of  less  than  two  seconds,  immediate 
synchronization  is  carried  out  and  the  the  current  scheduling  interval  is  modified  ro 
conform  with  the  new  Radar  Control  Group  time.   [Ref.  5:  p.  781 


Begin  Synchronization; 

If  I  to_R.resvnch_time  minus  Radar  Scheduler  time  is 
greater  than  2  seconds  then 

Wait  until  the  Radar  Scheduler  time  equals  the 
resynch_time; 

Else  if  the  resynch_time  minus  Radar  Scheduler  time  is 
greater  than  or  equal  to  zero  but  less  than  or  equal  to 
2  seconds  then 

Radar  Scheduler  time  gets  radar  time; 

End  Synchronization; 


Figure  4.5     Synchronization  Algorithm. 

This  module  consumes  the  synchronization  variable  within  the  Radar  Return 
(input)  Interface  data  structure.  It  does  not  produce  any  common  memory  interface 
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data.  Real  time  data  is  produced  for  use  by  the  Radar  Scheduler  when  a  clock  update 
occurs. 

The  modules  local  data  structures  have  not  been  designed.  The  algorithm  for 
Radar  and  Computer  Synchronization  is  given  in  Figure  4.5  . 
5.  Beam  Selection  Routines 

This  module  contains  procedures  used  in  the  Beam  Selection  process  of  the 
Radar  Scheduler.  The  code  for  the  Beam  Selection  process  is  actually  part  of  the  Radar 
Scheduler  code  and  the  functional  descnption  for  Beam  Selection  is  given  there.  This 
module  is  a  package  containing  two  procedures  and  a  function.  Their  functional 
descriptions  are  given  in  the  following  subsections  of  this  section. 

This  module  contains  one  local  data  structure,  a  working  pointer  p  which  is 
used  by  the  routines  in  this  module's  body.  The  pointer  is  declared  outside  of  the 
routines  inorder  to  increase  their  efficiency  and  prevent  neap  or  stack  over  flow  which 
wouid  occur  by  repeated  calls  to  these  procedures;  function. 

This  module  does  not  consume  or  produce  any  common  memory  data 
structures. 

a.  Add  Linked  List 

Functionally,  the  procedure  llend  is  used  to  insert  a  Radar  Event  Control 
Table  node  at  the  end  of  a  linked  list.  This  procedure  is  derived  form  the  PL/I-80 
module  RSM3A.  The  procedure  declaration  is  contained  in  the  Beam  Selection  module 
described  above. 

The  parameters  to  this  procedure  are  pointers,  q  and  s,  which  are  passed  by 
reference.  The  pointer  q  points  to  the  head  of  the  list.  The  pointer  s  points  to  the  node 
which  is  to  be  inserted  at  the  end  of  the  linked  list.  The  pointers  consumed  in  this 
procedure  are  Radar  Event  Control  Table  data  structures  local  to  the  Radar  Scheduler 
modules  only.  There  are  no  common  memory  interface  data  structures  consumed  by 
this  procedure. 

There  are  no  local  data  structures  produced  by  this  procedure.  The 
working  pointer  p  is  declared  in  the  body  of  the  Beam  Selection  Routines  module. 

The  algorithmic  description  for  this  procedure  is  given  in  Figure  4.6  . 

b.  Get  RECT  Node 

The  function  Get  RECT  Node  locates  the  first  available  Radar  Event 
Control  Table  node  from  the  pool  and  returns  a  pointer  to  that  node.  The  function 
also  resets  the  head  of  pool's  linked  list  to  the  next  available  node. 
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Begin  llend; 


If  first  list  q  is  null  then 
list  q  gets  node  s; 


Else 


Find  end  of  list  q; 

End  of  list  q  gets  node  s; 


End  [lend: 


Hgure  4.6     ilend  Aigorunm. 

There  are  no  common  memory  interface  data  structures  consumed  by  this 
procedure. 

There  are  ao  local  data  structures  produced  by  his  procedure.  The 
working  pointer  p  is  declared  in  the  body  of  the  Seam  Selection  R.outmes  module. 

The  aigonchmic  .description  of  this  function  ;s  given  in  Figure  4.7  . 


3egm  Gee  RECT  Node: 

If  pool  is  empty   then 

Create  a  new  pool  pointer; 

End  if; 

p  gets  pool  pointer; 

pool  pointer  gets  next  node  in  linked  list; 

Return  pointer  p; 
End  Get  RECT  Node; 


Figure  4.7    Get  RECT  Node  Algorithm. 

c.   Free  RECT  Node 

Functionally,  this  procedure  returns  an  unused  Radar  Event  Control  Table 
node  to  the  pool  of  available  nodes.  The  procedure  Free  RECT  node  together  with  the 
function  Get  RECT  Node  are  used  to  manage  pointer  storage. 
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There  are  no  common  memory  interface  data  structures  consumed  by  this 
procedure. 

There  are  no  local  data  structures  produced  by  this  procedure.  The 
working  pointer  p  is  declared  in  the  body  of  the  Beam  Selection  Routines  module. 

Figure  4.8  gives  the  algorithmic  description  of  the  procedure  Free  RECT 
Node. 


3egm  Free  RECT  Node: 

' 

Set  node  q's  Link  to  null; 

If  pool  is  empty  then 

pool  pointer  gets 

node 

q; 

Else 

insert  node  q  at  e 

:nd  of 

pool 

list; 

End  if: 

End  Free  RECT  Node: 

rigure  4.8     Free  RECT  Node  Algorithm. 

6.  Supplementary  Dwell  Processing 

The  function  of  the  Supplementary  Dwell  Processing  module  is  to  do  sufficient 
processing  on  each  selected  beam  to  ensure  enough  dwell  information  is  generated  for 
correct  transmission  by  the  radar.  The  minimum  information  required  is: 

the  scheduled  dwell's  transmission  time, 

the  dwell  index  number, 

the  stable  space  bearing  and  elevation  beam  position, 

the  radar  end  the  dwell  is  to  be  transmitted  from  and, 

the  radar  transmission  parameters. 
The  data  structures  used  by  this  module  have  not  been  decided  upon  [Ref.  5:  p.  82]. 
The  algorithm  for  this  module  has  not  been  written. 

7.  Dwell  Array  Face  Assignment 

The  function  of  this  module  is  to  assign  an  array  face  to  each  selected  beam. 
The  NTS  model  assumes  that  the  ship  is  not  underway  and  on  a  heading  of  000 
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degrees  true,  therefore  the  model  does  not  emulate  gyro  inputs.  Hence,  stable  space 
coordinates  equate  to  ship's  deck,  space  coordinates.  The  result  of  this  is  that  the 
transformation  matrix  and  array  face  bearing  limits  generated  by  the  Beam 
Stabilization  process  are  constant.  The  Assignment  module  is  used  to  select  the  array 
face  for  the  beam's  transmission  by  comparing  the  beam's  bearing  to  the  limits  found 
in  the  array  face  bearing  limits  table.  This  assignment  consumes  the  common  memory 
interface  data  for  array  face  bearing  limits.  No  common  memory  data  is  produced. 
[Ref.  5:  pp.  82-83] 

No  internal  data  is  consumed  by  this  module  and  there  are  no  locally  declared 
data  structures  in  this  module.  It  does  produce  the  face  assignment  data  for  the 
selected  beam  which  is  located  in  the  Radar  Event  Control  Table  data  structure. 

This  module  is  not  implemented  in  the  Radar  Scheduler  model.  An 
algorithmic  description  of  the  moduie  is  given  in  Figure  4.9  . 


Begin  Dwell  Array 

Face  Assignment; 

If  beam  beann 

g  is  between  first  limits  then 

Beam  face 

assignment  gets  ot\q\ 

Else  if  beam  bearing  is  between  second  limits  then 

Beam  face 

assignment  gets  two; 

Else  if  beam  bearing  is  between  third  limits  then 

Beam  face 

assignment  gets  three; 

Else 

Beam  face 

assignment  gets  four; 

End  Dwell  Array  Face  Assignment; 

Figure  4.9     Dwell  Array  Face  Assignment. 

8.  Comply  With  Radar  Doctrine 

The  function  of  this  module  is  to  ensure  that  the  selected  beam's  transmission 
parameters  comply  with  the  doctrines  imposed  by  the  program  operators. 

The  common  memory  data  consumed  by  this  module  includes  the  radar 
silence  flag,  produced  by  the  Command  and  Decision  User  services  process,  and  three 
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doctrine  commands  produced  by  the  Switch  Action  and  Display  process.  The  doctrine 
commands  consumed  are: 

•.     the  radar  transmitter  power  flag, 

•.     the  radar  power  option  flag  and, 

•.     the  inhibited  radiation  regions. 
This  module  does  not  consume  any  internal  data  and  there  are  no  locally  declared  data 
structures.   [Ref.  5:  p.  84] 

This  module  does  produce  data  for  the  Output  Channel  Control  Buffer  data 
structure  of  the  Radar  Event  Control  Tabie. 

This  module  is  not  implemented  in  this  program.   The  algorithm  for  this 
module  is  presented  in  Figure  4.10  . 


Begin  Comply  With  Radar  Doctrine; 

If  the  radar  siience  flag  is  false  then 

Set  the  transmitter  power  based  on  the  Haas  set 
by  the  Switch  Action  and  Display  process:" 

If  beam's  lie  within  [he  inhibited  radiation 
regions  then 

Set  transmitter  Hag  to  false; 

End  if; 

Else 

Set  transmitter  flag  to  false; 

End  if  else; 

End  Comply  With  Radar  Doctrine; 


Figure  4.10    Comply  With  Radar  Doctrine  Algorithm. 

9.  Satisfy  SPY-1A  Hardware  Constraints 

The  function  of  this  module  is  to  optimize  the  available  radar  resources  for 
dwell  transmission  during  each  scheduling  interval.  The  AEGIS  Program 
Specifications  call  for  the  use  of  digital  filters  to  optimize  dwell  transmission 
parameters.  In  the  NPS  model,  a  fixed  resource  percentage  scheme  is  used  to  calculate 
the  amount  of  radar  resources  consumed.  Each  radar  event  is  assigned  a  constant 
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resource  percentage  requirement.  As  the  requested  beams  are  selected  for  scheduleding, 
their  constant  resource  requirements  are  subtracted  form  the  total  radar  resources 
available.  The  total  radar  resources  for  the  start  of  each  scheduling  interval  is  100%. 
Beams  are  no  longer  selected  once  the  available  resources  have  been  depleted,  filenum 
rsm9 


Begin  Satisfy  Hardware  Constraints: 

Ascertain  the  beams  identity  and  set 
percent  eauat  to  beams  alloted  resource: 

Radar  resources  used  gets  raaar  resources  plus  percent; 

If  radar  resources  used  is  less  than  100%  then 

set  dweil  resources  used  ro  100%  minus  the 
radar  resources  used: 

Set  the  hardware  constraints  flag  to  true: 

£ise 

Set  raaar  resources  used  to  radar  resources  used 
minus  percent: 

Set  the  hardware  constraints  Mag  to  false: 

End  if  else: 

End  Satisfy  Hardware  Constraints; 


Figure  4.11     Satisfy  Hardware  Constraints  Algorithm. 

This  module  does  not  consume  or  produce  any  common  memory  data 
structures. 

The  input  parameters  to  the  Satisfy  SPY-1A  Hardware  Constraints  procedure 
are  as  follows: 

•  id  is  a  que  type  identifier  used  to  determine  what  percentage  of  resources  are 
required.  This  parameter  is  passed  by  value. 

•  rru  is  an  input/ output  parameter  containing  the  running  total  of  radar  resources 
used  for  the  current  scheduling  interval.  The  parameter  is  passed  by  reference. 

•  dru  is   an  input/output   parameter  containing   the   total   percentage   of  radar 
resources  consumed  after  selection  of  the  current  beam. 

•  hwc   is   a   boolean   output  parameter  which   is   set  to   true   if  the   hardware 
constraints  are  satisfied.  The  parameter  is  passed  by  reference. 

The  following  data  structures  are  locally  declared: 


51 


srch_pcnt  is  a  constant  representing  the  percentage  of  resources  allotted  for 
each  search  dwell. 

sr_pcnt   is  a  constant  representing  the  percentage  of  resources  allotted  for  each 
special  request  dwell. 

trk_pcnt  is  a  constant  representing  the  percentage  of  resources  allotted  for  each 
tracK  dwell. 

mssl_pcnt  is  a  constant  representing  the  percentage  of  resources  allotted  for 
each  missile  dwell. 

percent  is  a  temoorarv  variable  used  to  hold  the  percent  of  resources  being 

considered. 

The  algorithmic  description  for  the  Satisfy  Hardware  Constraints  procedure  is 
presented  in  Figure  4.11  . 

10.    Place  Dwells  Into  Dwell  Buffers 

The  function  of  this  module  is  :o  transmit  the  formatted  dwell  information  to 
the  two  external  dwell  buffers;  Formatting  is  complete  upon  satisfying  the  hardware 
constraints:  [f  the  seieciea  :>eam  satisfies  those  constraints,  then  it  is  transmitted  to  the 
external  dwell  buffers  for  raaar  transmission. 


Begin  Fill  External  Dwells; 

Point  to  the  current  Output  Control  Channel  Buffer; 

Set  the  Output  Control  Channel  Buffer  data  structure  to 
the  ocb_data  structure  of  the  Radar  Event  Control  Table; 

Point  to  the  Current  R_to_0  data  structure; 

Set  the  R  to  O  data  structure  to  the  appropriate  data 
fields  in  the  Radar  Event  Control  Table; 

End  Fill  External  Dwells; 


Figure  4.12     Fill  External  Dwells. 

This  procedure  consumes  the  current  pointers  to  the  external  dwell  buffers 
which  are  passed  by  reference  in  the  following  input/output  parameters: 

•  pi  and  p2  are  pointers  to  the  Output  Control  Channel  Buffer  common  memory 
data  structure. 

•  p3  and  p4  are  pointers  to  the  R_to_0  common  memory  data  structure. 

•  pr  is  a  pointer  to  the  Output  Control  Channel  Buffer  data  contained  in  the 
internal  Radar  Event  Control  Table  data  structure  for  the  current  the  current 
selected  beam. 
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There  are  no  other  locally  declared  data  structures  in  this  module.  Figure  4.12 
gives  the  algorithmic  description  of  this  procedure. 

11.  Radar  Load  Evaluation 

The  function  of  this  module  is  to  maintain  a  running  total  of  the  amount  of 
radar  time  being  expended  in  tracking  targets.  The  total  is  reset  to  zero  each  time  the 
Load  Evaluation  process  tells  the  Radar  Scheduler  to  reset  its'  track  time  counter. 
Beam  transmission  data  is  then  sent  to  the  Load  Evaluation  process.  This  module  is 
executed  only  if  the  selected  beam  has  satisfied  the  hardware  constraints.  [Ref.  5:  p. 
87] 

The  Load  Evaluation  module  consumes  the  common  memory  interlace  from 
the  load  evaluation  process  (TAB9.LIB).  The  data  structure  consumed  is  the  track  time 
counter  reset  flag.  The  common  memory  interface  information  produced  by  this 
moduie  includes  information  concerning  the  transmitter  duty  factor  for  the  current 
beam,  the  r.otai  time  spent  on  dummy  dwells  during  the  interval,  and  the  number  of 
horizon  and  above  horizon  search  beams  that  were  not  scheduled  during  the 
intervai.This  information  is  placed  in  the  common  memory  interface  of  TAB65.LIB. 
[Ref.  5:  p.  38] 

Internal  data  consumed  by  this  module  includes  the  beams  identity  and  the 
percentage  of  resources  used  by  the  beam.  No  internal  data  is  produced  by  this 
module.  Also,  this  module  does  not  use  any  locally  declared  data. 

The  algorithm  for  Load  Evaluation  is  given  in  Figure  4.13  . 

12.  Elapsed  Time  This  Interval 

The  function  of  this  module  is  to  compute  the  amount  of  time  spent 
scheduling  and  formatting  the  radar  beams  during  the  interval. 

No  common  memory  interface  data  is  consumed  or  produced  by  this  module. 

The  module  does  consume  the  internal  Radar  Scheduler  data  structure 
rs_time.  Each  time  the  module  is  executed  a  new  value  for  the  elapsed  time  is 
produced. 

The  Elapsed  Time  This  Interval  module  uses  the  following  local  data 
structures: 

•  et  is  an  input/output  parameter  that  holds  the  elapsed  time. 

•  rtim  is  an  input/ output  parameter  that  holds  the  Radar  Scheduler  time. 

•  oltim  is  a  variable  to  hold  the  old  time  value. 

Figure  4.14  shows  the  algorithm  used  by  the  Elapsed  Time  procedure. 
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Begin  Radar  Load  Evaluation; 

Increment  the  Duty  factor  variable  (fore  or  aft); 

Increment  the  phase  shifter  variable  (fore  or  aft); 

If  the  track,  time  counter  reset  variable  is  true  then 

Set  track  time  counter  to  zero' 
If  selected  beam  is  a  track  or  missile  beam  then 

Increment  the  track,  time  counter; 

If  the  selected  beam  is  a  dummy  dwell  then 

Increment  the  dummy  dwell  time  variable; 

If  the  selected  beam  is  a  search  beam  then 

decrement  the  unsked  search  beam  variable; 

End  Radar  Load  Evaluation; 


Figure  4.13     Radar  Load  Evaluation  Algorithm. 


Begin  Elapsed  Time; 

Old  time  gets  the  value  of  the  real  time; 

Real  time  gets  the  current  value  of  real  time; 

Elapsed  time  gets  elapsed  time  plus  real  time 
minus  the  old"time; 

Return  the  new  values  of  elapsed  time  and  real  time. 

End  Elapsed  Time; 


Figure  4.14    Elapsed  Time  Algorithm. 

13.    Radar  Event  Control  Table  Analysis 

This  module  is  designed  to  dump  selected  fields  from  the  Radar  Event  Priority 
List  and  the  Radar  Event  Control  Table  into  a  file  called  RSOUT.TXT.  When  the 
Radar  Scheduler  program  completes  its  execution,  the  file  will  contain  the  requested 
beams  from  the  Radar  Event  Priority  List  and  the  selected  beams  from  the  Radar 
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Event  Control  Table.  The  results  can  be  analyzed  by  comparing  the  requested  beam 
data  to  the  scheduled  beam  data. 


Begin  Radar  Scheduler  Dump; 

Traverse  the  Priority  Event  List; 

If  Priority  Event  List  status  is  true  then 

if  search  or  special  request  oeam  queue  then 

Traverse  search  or  special  request  beam  queue: 
Display  beam  identifier: 
increment  oeam  position  count; 

End  traverse  search  or  special  request  beam  queue; 

Else 

Traverse  Tack  or  missile  beam  queue: 

Displav  Oeam  identifier: 
Increment  beam  position  count: 

End  rraverse  track  or  missile  beam  queue: 

End  if  e:se: 

Start  new  ine  and  display  oeam  positions: 

2:se 

Display  "no  requests  this  interval"; 

End  if  else; 

End  traverse  Priority  Event  List; 

Traverse  Radar  Event  Control  Table; 

Display  beam  identifiers; 
Display  dwell  number; 
Display  resources; 

End  traverse  Radar  Event  Control  Table; 

End  Radar  Scheduler  Dump; 


Figure  4.15     Radar  Schedular  Dump  Algorithm. 

This  module  consumes  the  Radar  Event  Priority  List  common  memory  data 
structure.  It  does  not  produce  any  common  memory  data. 

This  module  also  consumes  the  Radar  Event  Control  Table  internal  data 
structure.  It  does  not  produce  any  internal  data. 
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The  local  variables  used  in  this  module  are  defined  below: 

dsh  is  a  string  constant  containing  a  dashed  line  for  formating  the  output. 

sptr  is  a  working  pointer  used  in  traversing  the  Radar  Event  Priority  List's 
search  or  special  request  beam  queue. 

tptr  is  a  working  pointer  used  in  traversing  the  Radar  Event  Prioritv  List's  track 
or  missile  beam  "queue. 

p  is  a  working  pointer  used  in  traversing  the  Radar  Event  Control  Table. 

Control  Table. 

The   dump   procedure   declared   in   this   moauie   uses    the   pointers   described 

above.  The  procedure  aiso  defines  the  following  local  data  structures: 

•  ctr  is  used  as  an  index  for  ira versing  me  Radar  Event  Priority  Event  list. 

•  start  is  a  variable  used  to  keep  track  of  the  starting  vaiue  used  in  the  "FOR" 
loop  control  structure. 

•  an  is  a  variable  used  to  keep  track  of  die  queue  position. 

The  r.he  algorithm  for  this  procedure  is  presented  in  Figure  4.15' . 
14    Free  Raaar  Event  Control  Table  Memory 

The  function  of  [his  moduie  is  ro  return  [he  Radar  Event  Control  Table  nodes 
to  the  pooi  of  available  nodes  at  the  end  of  each  scheduling  interval  so  they  can  be 
reused.  This  is  accomplished  by  linking  [he  Raaar  Event  Control  Table  to  the  Enu  of 
[he  node  pooi.  Then  as  the  nodes  are  required,  [he  Get  RECT  Node  function  from  the 
RSM5  module  returns  them  to  the  Radar  Event  Control  Table. 


Begin  Free  Memory; 

Find  the  end  of  the  RECT  node  pool; 

Insert  the  Radar  Event  Control  Table 
at  the  end  of  the  RECT  node  pool; 

Return  null  Radar  Event  Control  Table  pointer; 

End  Free  Memory; 


Figure  4.16     Free  Memory  Algorithm. 

The    Free    Memory   module   does   not   produce   or   consume   any   common 
memory  data  structures. 
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The  module  consumes  the  internal  data  structure,  Radar  Event  Control  Table, 
and  reproduces  the  pool  List. 

The  module  produces  the  local  pointer  p  for  use  by .  the  Free  Memory 
procedure.    Figure  4.16  contains  the  algorithmic  description  of  this  procedure. 

F.       RADAR  SCHEDULER  COMMON  SERVICE  ROUTINES 

The  Common  service  routines  used  are  designed  to  be  accessible  to  all  the  major 
processes.  For  simplicity,  the  common  service  routines  used  by  the  Radar  Scheduler 
program  have  been  Included  in  r.he  Global  module.  Some  of  :he  previously  designed 
Common  Service  Routines  functions  have  been  replaced  by  standard  Ada  packages, 
such  as  the  type  conversion  and  string  manipulation  functions.  The  procedures  await, 
advance,  ticket  etc..  are  expected  to  be  replaced  by  MCORTEX  procedures  and  appear 
only  as  stubs  in  this  program.  The  design  decisions  for  the  Common  Service  Routines 
implemented  in  this  model  are  included  here. 

i.   Random  Number  Generator 

The  Random  Number  Generator  is  a  function  that  returns  a  pseudo-random 
number.  The  function  uses  a  congruence  algorithm  to  generate  numbers  in  the  range 
from  zero  to  the  "t".    in  this  case  "t"  is  31099. 


Begin  Random  Number  Generator; 

If  this  is  the  first  call  to  this  module  then; 
set  x  equal  to  seed  number; 

Compute  the  random  number; 

set  "x"  equal  to  the  random  number; 

Return  the  value  of  "x"  to  the  caller; 
End  Random  Number  Generator; 


Figure  4.17     Random  Number  Generator  Algorithm. 

This  routine  does  not  consume  or  produce  any  common  memory  or  Radar 
Scheduler  data  structures.  The  module  does  consume  the  variable  "x"  which  is  declared 
in  the  Global  package  body  along  with  the  function.  LJnlike  the  function,  the  variable 
"x"  is  hidden  from  the  users  of  the   Random  Number  Generator.   This  variable  is 
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initialized  by  the  Global  package  body  and  thereafter  set  to  the  pseudo-random 
number  returned  after  each  execution  of  the  function.  The  variable  "x"  is  then  used  as 
a  seed  for  each  successive  call  to  the  function. 

The  data  structures  defined  by  this  function  are: 

•  a  is  a  constant  approximately  equal  to  the  square  root  of  "t". 

•  b  is  a  constant  that  is  relatively  prime  to  "t". 

•  t  is  a  constant  which  defines  the  upper  bound  of  the  numbers  generated. 

•  y  is  a  temporary  variable  used  to  calculate  the  random  number. 
Figure  4.17  presents  the  algorithm  for  the  random  function. 

2.  Clock  Routine 

This  Common  Service  Routine  is  designed  to  simulate  a  real  time  millisecond 
clock.  Each  time  this  function  is  called  the  variable  time  is  incremented.  This  new  value 
of  time  is  then  returned  to  che  calling  process. 

This  moduie  does  not  consume  or  produce  any  common  or  internal  data 
structures. 

The  only  data  siructure  used  by  this  function  is  the  variable  time,  which  is 
declared  in  the  package  body  of  the  Global  module.  The  Clock  Algorithm  is  shown  in 
Figure  4.13  . 


Begin  Clock; 

Increment  "time"; 

Return  the  value  of  "time"; 
End  Clock; 


Figure  4.18     Clock  Algorithm. 

3.  Initialize  Radar  Event  Priority  List 

The  purpose  of  this  procedure  is  to  initialize  the  data  fields  in  the  Radar  Event 
Priority  List.  It  is  designated  as  a  Common  Service  Routine  because  it  must  be 
executed  prior  to  any  process  using  the  list. 

This  routine  does  not  consume  any  common  memory  data  structures. 
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No  Radar  Scheduler  internal  data  structures  are  produced  or  consumed  by 
this  routine. 

There  is  only  one  local  variable  declared  by  this  procedure,  the  variable  "i", 
which  is  used  as  an  index  for  traversing  the  Radar  Event  Priority  List. 

The  Initialization  algorithm  is  presented  in  Figure  4.19  . 


Begin  Initialization; 

For  ";"  zers  one  ro  maximum  numoer  of  events  loop: 

Set  initial  values  for  the  common  data  fields; 

Assign  allowed  execution  periods  based  on 
the  index  "i"  and  the  description  given  in 
la  Die  &prilst; 

Assign  beam  queue  types  maximum  nodes  based  on 
the  index     "  and  cue  "description  given  in 
able  &prilst; 

Set  the  link  to  the  next  event  in  the  list; 

End  loop: 

Resei  last  link  to  zero: 

Assign  event  names  inaccordance  with  Table  &prilst; 

End  initialization: 


Figure  4.19     Priority  Event  List  Initialization  Algorithm. 
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V.  TEST  PLAN 

The  testing  requirements  for  the  NPS  model  of  the  Radar  Scheduler  process  have 
a  limited  set  of  goals.  The  primary  goal  is  to  test  for  logical  correctness  and  secondarily 
to  test  the  performance  of  the  code  generated  by  JANUS/ADA's  compiler. 

Testing  for  logical  correctness  entails  verifying  that  the  program  conforms  to  its 
specifications,  implements  the  iesign  algorithm,  and  produces  T.he  required  output. 
Testing  of  the  Raaar  Scheduler  process  for  this  thesis  was  done  primarily  by  a  'bottom 
up",  "white  box'  approach.  The  reason  for  taking  this  approach  as  opposed  to  a  top 
down  approach  is  that  the  basic  design  had  already  been  implemented  once  in  the 
PE/I-80  version  oi  the  ;oae.  Since  this  was  the  case,  it  was  felt  that  rfie  overall  design 
was  sound  and  [here  was  very  little  risk  in  implementing  and  resting  the  modules  from 
the  bottom  up.  Furthermore,  this  allowed  for  more  extensive  resting,  as  there  was  little 
need  for  module  stubs; 

A  [est  Harness  was  designed  for  each  module  with  an  erfort  towards  exercising,  as 
much  as  possible,  each  branch  of  the  code  for  :orrect  execution  and  robustness.  The 
subordinate  modules  were  tested  first.  The  test  Harnesses  were  then  expanded  10 
incorporate  the  modules  at  the  next  higher  level.  At  each  phase  of  the  testing  the  test 
harnesses  were  modified  to  allow  the  input  of  relevant  data  to  exercise  the  branches  of 
the  code  and  then  record  the  results  for  examination.  In  some  cases  print  statements 
were  inserted  into  the  code  to  ensure  that  a  particular  branch  was  being  executed 
properly. 

A.       DESIGN  AND  DOCUMENTATION  OF  TEST  MODULES 

1.  Search  Management  Test  Harness 

The  Search  Management  test  harness  is  made  up  of  two  modules,  the  Search 
Management  Initialization  module  and  the  Fill  Search  Queue  module.  Collectively 
these  two  modules  provide  the  search  and  special  request  beams  for  the  Radar 
Scheduler  Process. 

The  Search  Management  Initialization  module  is  executed  once.  Its'  purpose 
is  to  allocate  memory  for  search  nodes  (TAB1.LIB),  and  create  empty  request  queues 
for  each  search  and  special  request  event  in  the  Radar  Event  Priority  List  (TABO.LIB). 
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The  Fill  Search  Queue  module  is  responsible  for  filling  the  search  and  special 
request  queues  with  the  proper  beam  data.  The  data  supplied  by  this  module  includes 
the  beam  mode,  a  unique  beam  identifier,  beam  position,  instrumented  range,  blanking 
gates,  end  of  frame  indicator,  and  a  requestor  identity.  This  design  version  imposes  a 
static  set  of  beam  requests,  for  test  purposes.  Whenever  the  module  is  executed,  the 
same  set  of  beam  requests  are  placed  in  the  queues.  The  static  set  of  beam  requests  are 
used  to  facilitate  the  data  analysis  of  the  Radar  Scheduler  and  is  not  meant  to 
accurately  model  the  Search  Management  process.  The  source  code  for  the  Search 
Management  modules  is  contained  in  Appendix  D. 

2.  Track  Management  Test  Harness 

The  Track  Management  test  harness  is  composed  of  the  Track  Management 
module  (TRCM)  and  a  Track  Management  Initialization  module  (TMM1).  The 
Initialization  module  is  designed  to  allocate  memory  for  track  nodes  (TAB2.LIB)  and 
create  empty  request  queues  for  each  track  and  missile  event  in  the  Radar  Event 
Priority  List  (TABO.LIB) 

The  mam  Track  Management  module  is  used  to  search  through  the  Track  File 
correlating  track  modes  to  radar  track  event  modes.  When  a  correlation  is  found,  the 
track  is  added  to  the  Priority  Event  List's  request  queue.  This  module  does  not 
accurately  model  the  Track  Management  process  and  again  is  used  only  for  testing  the 
Radar  Scheduler  Source  code.  The  source  code  for  these  modules  is  located  in 
Appendix  D. 

3.  Detection  Processing  Initialization  Module 

The  Detection  Processing  Initialization  module  (DPM)  creates  the  Track  File 
and  initializes  its  data  fields  with  viable  data  for  testing  the  Radar  Scheduler.  The 
number  of  Track  File  nodes  initialized  is  determined  by  the  test  harness  operator  at  run 
time,  when  he  is  directed  to  provide  the  "number  of  tracks"  to  be  initialized. 
Calculation  of  the  data  field  values  in  the  track  node  are  based  on  the  values  returned 
by  the  pseudo-random  number  generator.  Therefore  successive  runs  of  the  test  harness 
with  identical  input  from  the  operator  will  generate  the  same  Track  File  data  each 
time.  The  source  code  for  this  module  is  located  in  Appendix  D. 

4.  Operator  Interface  Module 

The  Operator  Interface  module  provides  the  user  of  the  test  harness  the  ability 
to  alter  the  number  of  tracks  to  be  initialized,  the  desired  number  of  intervals  to  be 
run,  and  how  often  the  results  are  to  be  displayed.  Actually  the  results  are  sent  to  a  file 
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that  can  be  examined  by  the  user  after  the  test  run.  A  short  messages  is  printed  to  the 
screen  whenever  results  of  the  scheduling  interval  are  sent  to  the  file.  This  can  also  be 
used  to.  time  the  scheduling  interval  loop  without  the  overhead  of  the  routines  that  are 
only  executed  once  to  initialize  the  data  structures. 

The  operator  is  cautioned  that  using  a  very  large  number  for  the  number  of 
intervals  and  a  small  interval  display  delay  period  will  generate  a  very  large  file  of  test 
results  and  may  cause  a  heap  or  stack  overflow.  If  the  operator  desires  such  a  run, 
then  the  print  functions  in  RSM13.PKG  can  be  easily  modified  to  print  to  the  screen, 
by  eliminating  the  word  "Text"  from  the  print  commands. 

B.  DATA  ANALYSIS  METHODS 

The  Radar  Scheduler  model  was  designed  so  that  the  results  of  any  particular 
scheduling  interval  may  be  recorded  in  the  file  RSOUT.TXT.  For  each  scheduling 
interval  being  recorded,  [he  output  file  holds  a  section  01  information  on  the  requested 
beams  from  the  Radar  Event  Priority  List  and  a  section  of  information  on  dwells 
scheduled  from  the  Radar  Event  Controi  Taole. 

The  requested  beam  section  shows  the  scheduling  interval  number  and  lists  the 
events  in  their  current  oriority  order.  Along  with  each  event  is  a  list  of  the  requested 
beams  if  any,  and  their  position  in  the  request  queue.  All  the  beams  are  identified  by  a 
unique  beam  identifier. 

The  scheduled  dwell  section  shows  the  interval  number  the  dwells  were  scheduled 

in  and  a  list  of  all  dwells  scheduled.  For  each  dwell  the  following  is  provided: 

•.     the  unique  beam  identity  of  the  dwell, 

•.     the  percentase  of  resources  left  after  formatting  the  selected  beam  into  a  dwell, 
and 

•.     the  dwell  index  number  of  the  selected  beam. 

The  Radar  Scheduler's  output  is  analyzed  by  comparing  the  requested  beam 

identities  to  the  selected  beam  identites  of  the  scheduled  dwells.  The  results  recorded 

over  several  intervals  indicate  how  well  the  model  is  optimizing  the  radar  resources  and 

if  the  radar  events  are  being  scheduled  efficiently. 

C.  TIMING  ANALYSIS 

To  test  the  timing  of  Radar  Scheduler  program,  a  short  message  is  sent  to  the 
screen  each  interval  display  delay  period.  When  the  first  message  is  displayed,  the 
Radar  Scheduler  has  completed  its  initialization  of  data  structures  and  completed  the 
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number  of  scheduling  intervals  equal  to  the  display  delay  period.  In  order  to  avoid  the 
initialization  overhead  at  the  start  of  the  program,  timing  must  start  when  the  first 
message  appears  and  not  when  the  program  is  first  executed.  Then  the  operator  may 
end  timing  on  any  later  interval  display  delay  period.  This  way  the  operator  can  get  a 
good  approximation  of  the  time  it  takes  to  complete  one  scheduling  interval. 

In  order  to  calculate  the  average  scheduling  interval  time,  the  overhead  from  the 
terminal  display  and  writing  to  output  file  must  be  accounted  for.  To  account  for  this, 
the  assumption  is  made  that  the  time  co  print  to  the  screen  and  dump  the  results  to  the 
output  rile  is  approximately  equal  eacn  rime  :t  occurs,  fn  other  words,  the  interval 
display  procedure  ;akes  approximately  tlie  same  amount  d(  time  each  time  it  is 
executed. 

Let  "Tr"  equal  the  cotal  time  recorded  for  the  test  run.  Let  "Td"  equal  the  time  it 

takes  for  one  execution  of  the  display  procedure.    Let  Ti"  equai  the  execution  rime  for 

one  scheduling  interval.  To  calculate  Ti"  the  following  rest  procedure  was  used: 

•.  Three  runs  of  the  Radar  Scheduler  were  maae  using  the  same  input.  The  results 
were  recorded  and  their  average  was  used  as  "Tr"i 

a.  The  interval  display  delay  period  was  set  on  500. 

b.  The  number  of  intervals  was  set  to  1000. 

c:      Timing  was  started  on  the  first  interval  display  delay  period,  500. 

d.     Timing  was  stopped  on  the  last  interval  display  delay  period,  1000,  which 
causea  only  the  last  display  to  be  included  in  the  total' time  recorded. 

•.  Three  runs  of  the  Radar  Scheduler  were  taken  again  using  a  new  interval 
displav  delay  period.  The  the  run  times  were  recorded  and  again  the  average 
was  used  as'"Tr". 

a.  The  interval  display  delay  period  was  set  on  100. 

b.  The  number  of  intervals  was  set  to  1000. 

c.  Timing  was  started  on  the  fifth  interval  display  delay  period,  500. 

d.  Timing  was  stopped  on  the  last  interval  display  delay  period,  1000,  which 
caused  five  display  times  to  be  included  in  the  total  time  recorded. 

For  the  first  set  of  runs  the  following  equation  holds: 

Trl  =  500Ti  +  Td. 
The  second  set  of  runs  uses  the  formula: 

Tr2  =  500Ti  +  5Td. 
Solving  the  two  simultaneous  equations  for  Ti  yields: 

Ti  =  (5Trl-Tr2)/2000. 
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Test  runs  were  made  of  the  code  generated  by  JANUS/ADA  compiler  with  all 
the  standard  pragmas,  and  then  again  on  the  code  generated  when  the  pragmas  were 
turned  off.  The  pragmas  that  were  turned  on  and  ofT  during  compilation  are  shown  at 
the  beginning  of  each  source  code  module.  For  consistancy,  all  the  modules  include  the 
same  pragma  statements.  The  pragmas  that  were  turned  on  and  ofT  are:  arithcheck, 
rangecheck,  debug,  and  enumtab. 

The  arithmetic  check  pragma  controls  the  generation  of  arithmetic  overflow 
checks.  Code  is  generated  during  compilation  ro  check  all  mathematical  expressions 
when  this  pragma  is  turned  on.    rRef.  6:  p.  3-1] 

The  range  check  pragma  controls  the  generation  ot  range  onecks  for  subrange 
variables  and  array  subscripts.  The  range  check  code  is  generated  at  compile  time  when 
the  pragma  is  turned  on.   [Ref.  6:  p.  B-2] 

The  debug  pragma  controls  rhe  generation  ot  line  aumber  and  procedure  names. 
This  information  is  used  by  the  walkback  which  is  generated  after  a  run-time  error.  The 
code  generated  when  this  pragma  is  on  would  only  affect  performance  when  a  run-time 
error  occurs.   [Ref.  6:  p.  B-l] 

The  enumeration  :able  pragma  controls  the  generation  of  enumeration  tables. 
These  tables  are  only  necessary  when  the  programer  is  doing  [/O  with  enumeration 
types.  The  generation  of  these  tables  at  compile  time  does  not  affect  performance,  but 
it  does  use  a  lot  of  storage  space.   [Ref.  6:  p.  B-l] 

Since  the  above  pragmas  are  turned  on  by  default,  they  have  been  explicitly 
turned  of  in  the  code.  They  can  be  turned  back  on  at  compile  time  by  the  conditional 
compilation  feature.  When  this  feature  is  off,  as  it  is  by  default,  the  lines  preceded  by  a 
"@"  are  treated  as  comments.  If  the  conditional  compilation  is  turned  on  with  the  "c" 
command  at  compile  time,  then  the  lines  preceded  by  the  "@"  symbol  are  compiled. 
[Ref.  6:  p.  B-l] 

The  first  executable  code  was  generated  with  the  pragmas  on  and  the  second  was 
generated  with  the  pragmas  off.  The  test  results  are  shown  in  Table  4  . 

Run-time  test  results  of  the  code  produced  by  the  JANUS/ADA  compiler  showed 
almost  a  two  to  one  increase  in  speed  when  it  was  recompiled  with  the  arithmetic  and 
range  checking  features  turned  off.  This  shows  that  although  there  was  a  significant 
increase  in  speed,  it  was  not  without  sacrificing  some  of  features  that  the  Ada  language 
includes.  Even  with  the  pragmas  turned  off,  the  best  speed  of  213.4  milliseconds  is  still 
ten  times  the  median  scheduling  interval  time  of  21  milliseconds  required. 
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TABLE  4 
PERFORMANCE  RESULTS 

PRAGMAS    ON 

NUMBER  OF  TRACKS:  50 

NUMBER  OF  INTERVALS:  1000 

INTERVAL  DISPLAY  DELAY:  500 

NUMBER  OF  INTERVALS  TIMED:  500 

AVERAGE  RUN  TIME  Trl:  228.  58  sec 

NUMBER  OF  TRACKS:  50 

NUMBER  OF  INTERVALS:  1000 

INTERVAL  DISPLAY  DELAY:  100 

AVERAGE  RUN  TIME  Tr2:  231.  48  sec 

TIME  PER  SCHEDULING  INTERVAL  "Ti":  ...  0.4557  sec/int 

SCHEDULING  RATE:  2.2  int/sec 

PRAGMAS  OFF 

NUMBER  OF  TRACKS:  50 

NUMBER  OF  INTERVALS:  1000 

INTERVAL  DISPLAY  DELAY:  500 

NUMBER  OF  INTERVALS  TIMED:  500 

AVERAGE  RUN  TIME  Trl:  107.  49  sec 

NUMBER  OF  TRACKS:  50 

NUMBER  OF  INTERVALS:  1000 

INTERVAL  DISPLAY  DELAY:  100 

AVERAGE  RUN  TIME  Tr2:  110.  65  sec 

TIME  PER  SCHEDULING  INTERVAL  "Ti":  ...  0.2134  sec/int 

SCHEDULING  RATE:  4.  6  int/sec 


The  tests  were  run  on  the  Z-100's  8-Bit  microprocessor.  The  target  processor  is 
the  iSBC  86/12A  Single  Board  Computer  with  a  16-Bit  microprocessor,  which  will 
increase  the  performance.  However,  it  is  doubtfull  that  this  will  be  enough  to  over 
come  a  factor  often. 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 

This  thesis  has  developed  a  JANUS/ADA  model  of  the  Radar  Scheduler  process. 
The  model  is  a  first  effort  in  implementing  one  of  the  AEGIS  AN/ SPY- 1 A  Radar 
Control  Group  modules  in  JANUS/ADA  and  as  such  it  is  a  part  of  the  continuing 
research  effort  at  the  Naval  Postgraduate  School  to  test  the  feasibility  of  replacing  the 
AEGIS  main  frame  computer  suit  with  a  multi-microprocessor  system.  Additionally, 
the  Radar  Scheduler  provides  an  example  for  studying  the  performance  of  time  critical 
programs  written  in  ADA. 

The  design  of  the  Radar  Scheduler  model  incorporates  14  modules.  The  modules 
were  designed  to  be  integrated  into  the  overall  model  with  a  minium  of  changes 
required.  In  support  of  this.  Chapter  IV,  serves  as  the  Radar  Scheduler  Design 
Document  to  be  used  as  a  reference  for  the  future  implementation  and  integration  of 
the  Radar  Scheduler  Process  with  the  remaining  Radar  Control  Group  modules.  As 
such,  any  changes  to  "he  Radar  Scheduler's  design  shouid  be  reflected  in  the  design 
document. 

Logical  testing  of  the  individual  modules  was  increasingly  more  dificult  as  they 
were  integrated  into  the  main  program.  There  were  several  reasons  for  this.  First,  the 
number  of  logical  paths  to  be  examined  grew  very  rapidly  as  the  modules  were 
integrated.  In  some  cases,  the  lower  modules  had  tested  satisfactorily,  isolated  in  their 
own  test  harness.  Then  later,  while  acting  in  conjunction  with  the  higher  level  modules, 
they  developed  problems  which  were  not  accounted  for  by  the  test  harness.  For 
example,  the  dynamic  allocation  of  local  access  data  structures,  and  some  recursively 
designed  procedures,  functioned  well  until  they  were  stressed  by  the  load  of  the  Radar 
Scheduler  test  harness.  Under  this  stress,  stack  overflow  became  a  problem.  Declaring 
the  access  types  outside  the  procedures  in  the  package  body,  and  making  the  recursive 
procedures  iterative,  solved  the  problem. 

Determining  what  the  best  testing  criteria  is,  and  formulating  a  testing  strategy  is 
difficult  without  a  more  rigorously  defined  specification.  The  logical  correctness  of  the 
module  can  not  be  determined  from  statements  such  as  "in  a  timely  manner". 
However,  the  Radar  Scheduler  output  indicates  that  the  requested  beams  are  being 
scheduled  in  a  priority  order,  and  that  those  beams  that  are  not  scheduled  during  the 
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interval  are  being  reprioritized  and  scheduled  in  later  intervals.  The  radar  resources 
remaining  at  the  end  of  the  interval  indicate  that  the  resources  are  being  consumed 
until  there  is  no  longer  enough  to  fill  the  remaining  requests  for  that  interval. 

Two  conclusion  are  evident  from  the  preliminary  real-time  testing.  First,  the  code 
generated  with  the  range  and  arithmetic  checking  turned  off  executes  at  twice  the  speed 
of  the  code  normally  generated  by  the  compiler.  Second,  the  best  run-time  was  ten 
times  slower  than  the  median  scheduling  interval  time  required.  In  view  of  this,  further 
testing  shouid  be  done  to  isolate  the  cause.  The  most  time  intensive  portions  3f  the 
program  snouid  be  analyzed  rirst.  identification  should  be  made  by  measuring  the 
execution  time  for  the  most  likely  modules  and  weighting  the  results  by  the  number  of 
times  the  module  is  executed  by  the  Radar  Scheduler  process.  Once  the  modules  have 
been  identified,  the  actual  cause  of  the  time  deiay  can  be  asessed.  The  algorithms  and 
data  structures  can  be  examined  for  improvement.  This  way,  a  more  accurate 
accounting  of  the  moduie  design,  ana  the  feasibility  of  real-time  programming  in  ADA 
can  be  maae. 

The  supplementary  processes  (TRCM,  SRCM,  DRCM,  aid  \RCM)  were 
developed  as  test  harnesses  to  supply  the  Radar  Scheduler  with  radar  event  requests. 
These  processes  will  be  fully  implemented  in  the  Janus/ Ada  programming  anguage  as 
the  NPS  AEGIS  Project  progresses.  Ultimately  the  processes  will  be  integrated  into  a 
multi-microprocessor  model  of  the  Radar  Controller. 

To  completely  model  the  Radar  Controller,  several  major  tasks  remain.  First  the 
JANUS/ADA  language  interface  to  the  MCORTEX  system  must  be  completed,  so 
that  the  Radar  Scheduler  model  can  be  run  and  tested  in  a  true  concurrent  multi- 
microprocessor  environment.  The  information  gained  from  this  will  be  valuable  to  the 
future  programmers  of  the  remaining  processes.  Next  the  Track  Processing  portion  of 
the  Radar  Control  Group  should  be  implemented.  This  portion  is  expected  to  be 
numerically  intensive  and  should  provide  a  good  basis  for  testing  the  performance  of 
the  code  produced  by  the  JANUS/ADA  compiler  and  the  interaction  of  processes  on 
seperate  processors. 

When  the  remainder  of  the  processes  have  been  completed,  the  Radar  Controller 
model  can  be  evaluated  as  a  whole.  At  that  time  actual  efficiency  measurements  can  be 
made  of  the  Radar  Controller  model  and  the  effects  of  the  Ada  programming  language 
in  a  real-time  multiprocessor  programming  environment  can  be  asessed. 


67 


APPENDIX  A 
COMMON  MEMORY  INTERFACE  SOURCE  CODE 

--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  3  Dec  86 

--  MODULE  TYPE:  External  data  structure 

--  PURPOSE:  Common  memory  interface  to:  Radar  Scheduler,  Search  Management 

--  and  Track  Management  orocesses 

—  NAME:  Priority  Event  List  ...  TABO. LIB 

--  This  data  structure  is  the  list  of  radar  events  in  priority  order. 
--  Each  element  _n  the  list  holds  information  on  the  event  queue  it 
--  points  to. 

pragma  arithcheck(off ) ;  pragma  debug(off) ; 

pragma  enumtahc.off )  ;    pragma  rangecheck(off )  ; 
@  pragma  arithcheck(on)  ;  pragma  debug"(on)  ,- 
@  pragma  anumtaoi on; ;    pragma  rangecheck(on) ; 

WITH  tabl , tab2 ; 

PACKAGE  tabO  IS 

io_anhnc:  CONSTANT  INTEGER  :.=  4; 
max_pri:  CONSTANT  INTEGER:-  26; 

TYPE  QueType  IS  ■;  search, speciai_.-equest,  track, missile)  ; 

USE  tabl ,  tao2  ,- 

TYPE  3eamOue  IS  RECORD 
CASE  kind:  QueType  IS 

WHEN  search  |  special_request  => 

Snode :  SearchPtr;-  --  see  TAB1.LIB 

WHEN  track  |  missile  => 

Tnode:  TrkPtr;  --  see  TAB2.LIB 

WHEN  others  => 
null ; 
END  CASE; 
END  RECORD; 


TYPE  pri_lst_info  IS  RECORD 
status 
eventnm 
max_nodes 
que_id 
que_ptr 
enhnc 
b_pri 
c_pri 
ltx 

allwd  ltx 
slct_f\lg 
nxt 


BOOLEAN ; 

string(40) ; 

INTEGER; 

QueType ; 

BeamQue ; 

BOOLEAN ; 

INTEGER; 

INTEGER; 

INTEGER ; 

INTEGER; 

BOOLEAN; 

INTEGER;     --  pointer  to  next  priority  in  list 


END  RECORD; 
TYPE  PriLstPtr  IS  ACCESS  pri_lst_info; 
TYPE  PriLstArray  IS  ARRAY(1 . .max_pri)  OF  PriLstPtr; 
pri_lst  :  PriLstArray; 
END  tabO; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  3  Dec  86 

--  MODULE  TYPE:  External  data  structure 

--  PURPOSE:  Common  memory  interface  to:  Radar  Scheduler,  Search  Management, 

--  and  Track  Management  processes 

--  NAME:  Priority  Event  List  ...  TABO.PKG 

pragma  arithcheck(off ) ;  pragma  debug(of f ) ; 

pragma  enumtab(off) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on); 
@  pragma  enumtab(on) ;    pragma  rangecheck(on) ; 

PACKAGE  BODY  tabO  IS 

i : INTEGER; 

BEGIN 

FOR  i  IN  l..max_pri  LOOP 

pri_lst(i):=  MEW  pri_list_info; 

END  LOOP; 
END  tabO; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  30  Sep  86 
--  MODULE  TYPE:  external  table 
--  PURPOSE:  Common  memory  interface 
--  NAME:  Search  Node .. .TAB1 .LIB 

--  This  interface  is  a  search  beam  node.  It  acts  as  a  template  for  the 
--  nodes  which  make  up  the  horizon  search,  above  horizon  search  and 
--  special  request  queues. 

--  The  Search  Management  Process  fills  the  queue  and  the  radar  Scheduler 
--  Process  empties  it. 

pragma  arithcheck(of f ) ;  pragma  debug(off ) ; 

pragma  enumtab(off ) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug"(on); 
@  pragma  enumtab(on; ;    pragma  rangecheck(on) ; 

PACKAGE  cabl  IS 

TYPE  BeamPosition  IS  RECORD 

azim  :  INTEGER; 

elev  :  INTEGER; 
END  RECORD; 

TYPE  SrchData  13  RECORD 


INTEGER ; 
string(3 ) ; 
3eamPosxtion; 
INTEGER: 
INTEGER ; 


mode 
bid 

beam_posit 
inst^rge 
5tc_iana 

doctJblnk_gte :  INTEGER; 
:^t;-_oxnK_gT:e  :  INTEGER; 
eof  Tndic   :  BOOLEAN; 
req~id     :  INTEGER; 
END  RECORD; 

TYPE  SrchDatPtr  IS  ACCESS  SrchData; 

TYPE  SearchNode; 

TYPE  SearchPtr  IS  ACCESS  SearchNode; 

TYPE  SearchNode  IS  RECORD 

info:  SrchDatPtr; 

nxt  :  SearchPtr; 
END  RECORD; 

srch_node:  SearchPtr; 

END  tabl; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  24  Jun  86 

--  MODULE  TYPE:  external  table 

--  PURPOSE:  common  memory  interface 

--  NAME:  Track  Node  ...  TAB2.LIB 

--  This  data  structure  is  a  track  request  beam  node.  It  acts  as  an  overlay 
--  for  the  track  request  queues  resident  in  the  Priority  List.  The  Track 
--  Management  Process  fills  the  queues  with  requests  for  track  beams  and 
--  the  Radar  Scheduler  Process  empties  them  as  the  track  beams  are  scheduled. 

pragma  arithcheck(off ) ;  pragma  debug(off'); 

pragma  enumtab(off) ;    pragma  rangecheck(off ) ; 
@  pragma  aritftcheckCon J  ;  pragma  debug"(on)  ; 
i§  pragma  enumtabf on; ;    pragma  rangecneck(  on)  ; 

WITH  tab7 r 

PACKAGE  tab 2  IS 

USE  tab7 ; 

TYPE  Trklnfo  IS  RECORD 

mode    :  INTEGER ; 

bid    :  strmcuS)  ; 

p_trk:  PtrTrkFile;   --  3ee  :AB7,LI3 
END  RECORD; 

TYPE  IrackNode; 

TYPE  IrkPtr  "S  ACCESS  TracxNode ; 

TYPE  TrackNode  IS  RECORD 

info   .  Trklnfo : 

nxc   :  rrkP.tr; 
END  RECORD; 

trk_node:  TrkPtr-; 

END  tab2; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  24  Jun  86 

--  MODULE  TYPE:  external  table 

--  PURPOSE:  common  memory  interface 

--  NAME:  I_to_R  ...  TAB3*.LIB 

--  This  table  is  an  interface  data  structure  which  communicates  SPY-1  radar 
--  status  to  the  Radar  Scheduling  Process. 

pragma  arithcheck(off ) ;  pragma  debug(off) ; 

pragma  enumtab(off ) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on); 
@  pragma  enumtab(on) ;    pragma  rangecheck(on) ; 

PACKAGE  tab3  IS 


TYPE  SPY1  .status  IS  ?.ECORD 
resynch_time  :  INTEGER; 
loop_con  :  INTEGER: 
xmsn_status   :  BOOLEAN; 

END  RECORD; 


TYPE  StatPtr  IS  ACCESS  5PYl_3tatus 
I  to  R:  StatPtr.; 


IND  tao3 
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—  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  24  Jun  86 

--  MODULE  TYPE:  external  table 

--  PURPOSE:  common  memory  interface 

--  NAME:  A_tO_R  ...TAB4.LIB 

--  This  interface  data  structure  communicates  RCS  commands  to  the  Radar 
--  Scheduler  to  aid  in  the  formating  of  the  radar  dwell  buffer. 

pragma  arithcheck(off ) ;  pragma  debug(off'); 

pragma  enumtab(of r ) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on); 
@  pragma  enumtab(on);    pragma  rangecheck(on) ; 

PACKAGE  tab4  13 

TYPE  InhibicReaion  IS  RECORD 

start  bng  : INTEGER; 

stop_Bng   : INTEGER; 
END  RECORD; 

TYPE  OpDoct  IS  RECORD 

mtrks     : INTEGER; 

mintvls    :  INTEGER; 

dplvrect  : INTEGER; 
END  RECORD; 

TYPE  RCS  command  IS  RECORD 
pwr_flg       :  300LEAN; 
rad_pwr„option:  BOOLEAN; 
radZlnhibt_regions :  array(1..5)  OF  InnibitRegion; 

OD_aOC~         :  OdDoCI; 
END  RECORD : 

TYPE  Ptr_A  to_R  13  ACCESS  RCS  command; 

A_tO_R  :  Ptr_A_tO_R; 


END  tab4; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  22  Oct  86 
--  MODULE  TYPE:  external  table 
--  PURPOSE:  common  memory  interface 
--  NAME:  A_to_R  ...TAB4.PKG 

--  This  interface  data  structure  communicates  RCS  commands  to  the  Radar 
--  Scheduler  to  aid  in  the  formating  of  the  radar  dwell  buffer. 

pragma  arithcheck(off ) ;  pragma  debug(of f) ; 

pragma  enumtab(of f ) ;    pragma  rangecheck(of f ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on); 
@  pragma  enumtab(on);    pragma  rangecheck(on) ; 

PACKAGE  BODY  tab4  IS 

BEGIN 

A_to_R:=  NEW  RCS_command; 

END  tab4; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  11  Oct  86 

--  MODULE  TYPE:  External  Table 

--  PURPOSE:  Common  Memory  Interface 

--  NAME:  C_to_R  ...  TAB5.LIB 

--  This  table  is  an  interface  between  the  C&D  User  Services  Process 
--  and  the  Radar  Scheduling  Process. 

pragma  arithcheck(of f ) ;  pragma  debug(off ) ; 

pragma  enumtab(off ) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on); 
@  pragma  enumtab(on);    pragma  rangecheck(on) • 

PACKAGE  tab 5  15 

rdr_silnce:  BOOLEAN; 

END  tab 5  ; 
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—  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  11  Oct  86 
--  MODULE  TYPE:  External  Table 
--  PURPOSE:  Common  Memory  Interface 
--  NAME:  B_to_R  ...  TAB6.LI3 

--  This  interface  data  structure  communicates  information  concerning 
--  array  face  limits  and  ships  motion  matrix  to  the  Radar  Scheduler 
--  Process.  The  information  is  developed  in  the  Beam  Stabilization 
--  Process. 

pragma  arithcheck(_off )  ;  pragma  debug(off )  ; 

pragma  enumtab(of r ) ;    pragma  rangecheck(off ) ; 
(?  pragma  arithcheck;  on)  ,-  pragma  debug ( on )  ■ 
§  pragma  anumcab(on) ;    bragma  rangecheck(on) ; 

PACKAGE  "ab6  [S 

TYPE  L_R_Limits  IS  RECORD 

iimit_Ieft:  INTEGER; 

right_limit:  INTEGER; 
END  RECORD; 

TYPE  FaceLimits  IS  ARRAY.(  11.-4 )  OF  C_R_Uimits.; 

TYPE  MbtionMatrix  ZS  RECORD 

X_shiD_dot :  INTEGER ; 

fj~.ship_.dot:  INTEGER 

r.ool       :  INTEGER 

oitch      :  INTEGER 

Vaw        :  INTEGER 
END  'RECORD; 

TYPE  B_R  Interface; 

TYPE  3toR  IS  ACCESS  B_R_Ihter.f ace 

TYPE    3_R_Interface    CS    RECORD 

f  acej"ancenna_^imi  C3 

ships  motion  matrix 

azim_Timit_sTope 
END   RECORD; 

B_tO_R:  BtoR; 

END  tab6; 


FaceLimits ; 

MotionMatrix; 

INTEGER; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  22  Oct  86 

--  MODULE  TYPE:  external  table 

--  PURPOSE:  common  memory  interface 

--  NAME:  Track  File  ...TAB7.LIB 

--  This  external  table  is  the  radar  control  system  track  file.  The  data 
--  structure  is  a  linked  list  based  on  a  pointer  which  is  passed  between 
--  processes  which  require  access  to  the  track  file  for  data  on  tracks. 

pragma  arithcheck(off ) ;  pragma  debug(of f ) ; 

pragma  enumtab(of f)  ,•    pragma  rangecheck(off )  ; 
@  pragma  arithcheck(on) ;  pragma  debug(on); 
@  pragma  enumtab(on) ;    pragma  rangecheck(on) ; 

WITH  Longops; 

PACKAGE  tab 7  IS 


USE  Longops; 

TYPE  Position  IS  RECORD 


x 

y 

slnc_rnge 
x_do  t 

y_do  z 
z_dot 
rge_dot 
[ND    RECORD; 


INTEGER 

INTEGER ; 

INTEGER' 

Lona_Int:eger 

INTEGER ; 

INTEGER 

INTEGER 

INTEGER 


--  uana  Inteaer  zrom  LonaoDs  packaae 


TYPE  TimAlwdDwl  15 
msw  :  INTEGER : 
Isw  :  INTEGER; 

END  RECORD; 


RECORD 


TYPE  UpdtPosit  IS  RECORD 

msw_rate_filter  :  INTEGER; 
lsw_rate_filter  :  INTEGER; 

END  RECORD; 

TYPE  PredTimLst  IS  RECORD 
msw_azim_elev  :  INTEGER; 
lsw_azim_elev  :  INTEGER; 

END  RECORD; 

TYPE  DetectRnge  IS  RECORD 

msw  :  INTEGER; 

lsw  :  INTEGER; 
END  RECORD; 

TYPE  TimDetect  IS  RECORD 

msw  :  INTEGER; 

lsw  :  INTEGER; 
END  RECORD; 


TYPE  TrkData  IS  RECORD 


mode 

bid 

priority 

posit 

trk_xsitn_flag 

ctl  grp  trk  num 

ctsly      ~ 

xgte_bin_num 

?red_azim 
ow_elev  trk_flg 
log_ampl3_est 


INTEGER; 

string(3) ; 

INTEGER; 

Position; 

BOOLEAN; 

INTEGER; 

INTEGER; 

INTEGER, 

INTEGER, 

BOOLEAN; 

INTEGER; 
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xmit_reqflg 
sim_tgt_flg 
END  RECORD; 


:  BOOLEAN; 
:  BOOLEAN; 


TYPE  TrkDatPtr  IS  ACCESS  TrkData; 

TYPE  TgtData  IS  RECORD 

tim_alwd_dwl    :  TimAlwdDwl; 
mfar  trk_num    :  INTEGER; 
wcs_Tdx  :  INTEGER,; 

updt_tim_posit   :  UpdtPosit; 
pred  tim_lst    :  PredTimLst; 
dwl_b~twn_tim    :  INTEGER; 
nxt_trk  xate_bin:  INTEGER; 
prev_trk"_xgte_bin:  INTEGER; 


freq 

frad 


ari:3t:_noise. 
least_noise^ 
vaiid_data_"tlg 
lost  trk  count 


INTEGER 
INTEGER: 
BOOLEAN; 
INTEGER; 


nxt_tim_cbl_entry :  INTEGER; 

--he=l ,me=2 , le=3 , ale=4,mti=5 ,passv=6,missile=7 ,cvr_plse=8 
trk_mode        :  INTEGER; 


rcvr_s  ta  cus  fig 
typl _pas3v_ilg 
:vp22pas3V_jflg 
drp_crk_fig 


300LEAN : 
BOOLEAN ; 
BOOLEAN : 
BOOLEAN : 


■air=l , surf aca=2 , clutter=3 
•X   class  :    INTEGER: 


■-hostile=l 
:rk   id 


-:ig 


:riendlv=2 . unknown=3 
:  INTEGER; 


wcs 

sm  tK_amp la_c  oun  t 
rnge_accel_f lg 
detect_rnge 
tim_detec£ 
caus_lost_data_pt 
END  RECORD; 

TYPE  TrkFile: 

TYPE  PtrTrkFile  IS  ACCESS  TrkFile; 

TYPE  TrkFile  IS  RECORD 


BOOLEAN ; 
INTEGER; 
BOOLEAN; 
DetectRnge; 
TimDetect; 
:  INTEGER;  --unknown  pointer  type? 


beam  data 
tgt_3ata 
nxt_trk 
END  RECORD; 


TrkDatPtr; 
TgtData ? 
PtrTrkFile; 


ptrk:  PtrTrkFile; 
trk_file:  PtrTrkFile; 


END  tab7; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  17  Nov  86 

—  MODULE  TYPE:  external  table 

--  PURPOSE:  common  memory  interface 

--  NAME:  Track  File  . ..TAB7.PKG 

--  This  external  table  is  the  radar  control  system  track  file.  The  data 
--  structure  is  a  linked  list  based  on  a  pointer  which  is  Dassed  between 
--  processes  which  require  access  to  the  track  file  for  data  on  tracks. 

pragma  arithcheck(of f )  ;  pragma  debug(off); 

pragma  enumtab(of f ) ;    pragma  rangecheck( off ) ; 
@  pragma  arithcheck(on)  ;  pragma  debug"(on)  ; 
i§  pragma  enumcab(on)  ;    bragma  rangecheck(on)  - 

PACKAGE  30DY  :ao7  13 


3EGIM 


ptrk:=  MEW  TrkFile,- 

perk.beam_data:=  NEW  TridData; 
trk_file:=  MEW  TrkFile; 
trk  file. beam  data :=  MEW  TrkDaca: 
ptr£:.=  trk^file; 

or.rK.beam  iaca:=  trk  file. beam  laca: 


3ND  caD7 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  11  Oct  36 

--  MODULE  TYPE:  External  Table 

--  PURPOSE:  Common  Memory  Interface 

—  NAME:  F_to_R  ...  TAB8.LIB 

--  This  interface  data  structure  contains  the  frequency  and  waveform 
--  information  required  by  the  Radar  Scheduler  Process  to  complete 
--  formatting  of  selected  radar  dwells. 

pragma  arithcheck(off ) ;  pragma  debug(of f) ; 

pragma  enumtab(off ) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  oragma  debug(on); 
@  pragma  enumtao< on) ;    pragma  rangecheck(on) ; 

PACKAGE  caD8  IS 

raax_dwelis:  CONSTANT  INTEGER:-  10;  --  not  previously  defined,  10  ? 

TYPE  mtiRec  IS  RECORD 

pri        :  INTEGER; 

dwl_Length:  INTEGER; 
END  RECORD; 

TYPE  msleSec  IS  RECORD 

UDlnk  freq:  INTEGER; 

x:m   freq   :  INTEGER: 
END  RECORD ; ' 

TYPE  WaveFormRec  CS  RECORD 

fr.eq_chnl   .•  INTEGER 

£re.q_band      :    INTEGER 

phasel_code:  INTEGER 

phase2__code :  INTEGER 

mti        :  mtiRec  ,• 

.nsie       :  msTeRec; 

inhib_freq_chnl;  INTEGER; 
END  RECORD; 

TYPE  F_to_R  IS  ACCESS  WaveFormRec; 

TYPE  InfoWaveForm  IS  ARRAY(1 . .max_dwells)  OF  F_to_R; 

waveform:  InfoWaveForm; 

END  tab8; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  11  Oct  86 
—  MODULE  TYPE:  External  Table 
--  PURPOSE:  Common  Memory  Interface 
--  NAME:  F_tO_R  ...  TAB8.PKG 

--  This  interface  data  structure  contains  the  frequency  and  waveform 
--  information  required  by  the  Radar  Scheduler  Process  to  complete 
--  formatting  of  selected  radar  dwells. 

pragma  arithcheck(off ) ;  pragma  debug(off); 

pragma  enumtab(off) ;    pragma  rangechecfc(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on) ; 
@  pragma  enumtab(on) ;    pragma  rancecheck(on) ; 

PACKAGE  30DY  zao8    IS 

1:  INTEGER; 

BEGIN 

FOR  i  IN  1. .max_dwells  LOOP 

waveform(i) :=  NEW  WaveFormRec; 

END  LOOP; 
END  tabS; 
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--  OWNER:  AEGIS  Modeling  Group 

—  DATE  OF  LAST  UPDATE:  11  Oct  86 
--  MODULE  TYPE:  External  Table 

—  PURPOSE:  Common  Memory  Interface 
--  NAME:  L_to_R  ...  TAB9.LIB 

--  This  interface  data  structure  contains  the  flag  which  indicates 
--  reset  time  for  the  track  counter.  This  flag  is  used  by  the  Radar 
--  Scheduler  Process  to  format  track  dwells. 

pragma  arithcheckfoff ) ;  pragma  debug(off ) ; 

pragma  enumtab(off ) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on); 
@  pragma  enumtab(on) ;    pragma  rangecheck(on) ; 

PACKAGE  tab 9  IS 

trk_tim_ctr_resei::  300LZAN; 

END  tab9; 
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OWNER:  AEGIS  Modeling  Group 
DATE  OF  LAST  UPDATE:  11  Oct  86 
MODULE  TYPE:  External  Table 
PURPOSE:  Common  Memorv  Interface 
NAME:  Missile  Downlink  Messaqe  . 


TAB10.LIB 


--  This  table  holds  the  communication  information  required  for 
--  downlink  data  from  own  ship's  SM-2  missiles. 

pragma  arithcheck(off ) ;  pragma  debug(off ) ■ 
pragma  enumtab(of f ) ;    pragma  rangecheck(of f ) ; 

@  pragma  arithcheck(on) ;  pragma  debugton) ; 

@  pragma  enumtab(on) ;    pragma  rangecheck(on) ; 


PACKAGE  tab 10  13 

num_mssi_nsgs :  CONSTANT  INTEGER::-  10 
TYPE  DwnlinkRec  IS  RECORD 


nor  previously  defined,  L0? 


pr~_one 
prt_:wo 
prt_three 
?rt_four 
prt_five 
prt_six 
prt_seven 
prt*  eight 
•ND  RECORD": 


INTEGER 
INTEGER 
INTEGER 

INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 


TYPE  P.trMsslDwnlnk  IS  ACCESS  DwnlinkRec; 

TYPE  DwninKArray  IS  ARRAY:(l....num_mssl_msgs)  OF  PtrMsslDwnlnk; 
Tissi_iwnlnk:  "DwnlnkArray ; 
END  ;aol0  : 
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—  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  11  Oct  86 

--  MODULE  TYPE:  External  Table 

--  PURPOSE:  Common  Memory  Interface 

--  NAME:  Missile  Downlink  Message  ...  TAB10.PKG 

--  This  table  holds  the  communication  information  required  for 
--  downlink  data  from  own  ship's  SM-2  missiles. 

pragma  arithcheck(off ) ;  pragma  debug(off); 

pragma  enumtab(off ) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on); 
@  pragma  enumtab(on);    pragma  rangecheck(on) ; 

PACKAGE  30DY  tab 10  IS 

1:  INTEGER; 

BEGIN 

cOR  1  IN  I..  p.umr_nssi_nsgs  LOOP 

ms3i_dwnlnk(i) :=  NEW  DwniinkRec; 
END  LOOP; 
END  :abi0? 
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OWNER:  AEGIS  Modeling  Group 
DATE  OF  LAST  UPDATE:  11  Oct  86 
MODULE  TYPE:  External  Table 
PURPOSE:  Common  Memory  Interface 


a. 


--  NAME:  R_to_S  ...  TABU. LIB 

--  This  interface  data  structure  contains  the  replenishment  flags 
--  which  inform  the  Search  Management  Process  which  search  queues 
--  require  filling.  The  Radar  Scheduler  Process  sets  the  flags  as 
--  necessary  when  it  has  used  a  preset  number  of  search  request 
--  beams. 

pragma  arithcheck(of f ) ;  pragma  debug(off<)  ; 

pragma  enumtab(ofr) :    pragma  rangechecfc(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug^on); 
t§  pragma  enumtab(on) ;    pragma  rangecheck(on) ; 

PACKAGE  tabll  IS 

TYPE  RtoS  IS  RECORD 

hs_que_repln:  BOOLEAN; 

ahs_que_rsoln:  BOOLEAN; 
END  RECORD; 

TYPE  RtoSPtr  IS  ACCESS  RtoS r 

R_tO_S:  RtoSPtr; 

END  tabll; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  11  Oct  86 
--  MODULE  TYPE:  External  Table 
--  PURPOSE:  Common  Memory  Interface 
—  NAME:  R_tO_S  ...  TAB11.PKG 

--  This  interface  data  structure  contains  the  replenishment  flags 
--  which  inform  the  Search  Management  Process  which  search  queues 
--  require  filling.  The  Radar  Scheduler  Process  sets  the  flags  as 
--  necessary  when  it  has  used  a  preset  number  of  search  request 
--  beams. 

pragma  arithcheck(off ) ;  pragma  debug(off ) ; 

pragma  enumtab(off ) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on); 
!§  pragma  anumtab(on);    pragma  rangecheck(on) ; 

PACKAGE  30DY  tabll  IS 

BEGIN 

R_tO_S:=  NEW  RtoS; 

END  tabll; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  30  Sep  86 

--  MODULE  TYPE:  external  table 

--  PURPOSE:  common  memory  interface 

--  NAME:  R_to_0  ...  TAB32.LIB 

--  This  table  is  the  interface  between  the  Radar  Scheduler  Process  and  the 
--  Radar  Output  Process. 

pragma  arithcheckfoff ) ;  pragma  debug(off) ; 

pragma  enumtab(of f ) ;    pragma  rangecheck(off ) ; 
@  p'ragma  arithcheck(on) ;  pragma  debug(on)  ; 
@  pragma  enumtab(on);    pragma  rangecheck(on) ; 

PACKAGE  tab 3 2  IS 


TYPE  DwlData  13  RECORD 

node 

race 

sub_mode 

dwl_idx 

beam_purpose 

dwl_start_idx 

doc t_unb Ink  gates 

rlutter  unb Ink  gates 
3ND  RECORD: 


INTEGER 
INTEGER 
ARRAY (I 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 


2)  OF  INTEGER; 


TYPE  RtoO; 

TYPE  PtrRtoO  13  ACCESS  RtoO; 

TYPE  RtoO  IS  RECORD 

3wl  data  :  DwiData; 

.ink     :  PtrRtoO: 
END  RECORD: 


R  to  0 


'trRtoO 


TYPE  ROPtrArray  IS  ARRAY(1 
ptr_r_to_o:  ROPtrArray; 

END  tab32; 


2)  OF  PtrRtoO; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  23  Oct  86 

--  MODULE  TYPE:  external  table 

--  PURPOSE:  common  memorv  interface 

--  NAME:  R_tO_0  ...  TAB32.PKG 

--  This  table  is  the  interface  between  the  Radar  Scheduler  Process  and  the 
--  Radar  Output  Process. 

pragma  arithcheck(of f ) ;  pragma  debug(off) ; 

pragma  enumtab(of f ) ;    pragma  rangecheck(of f ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on); 
d  pragma  enumtab(on);    pragma  rangecheck(on) ; 

PACKAGE  30DY  tab32  IS 

BEGIN 

otr  r_to_o (1):=  MEW  RtoO; 
ptr_r_to_o(2) :=  MEW  RtoO: 
ptr_ r_to_o(l) .link:=  null; 

ptr_r_to_o(2/ .link:=  null; 

END  ".3032; 
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OWNER:  AEGIS  Modeling  Group 
DATE  OF  LAST  UPDATE:  30  Sep  86 
MODULE  TYPE:  data  buffer 
PURPOSE:  internal  data  structure 
NAME:  Output  Control  Channel  Buffer 


.TAB40.LIB 


--  This  interface  data  structure  is  a  buffer  between  the  Radar  Control 

--  program  and  the  Radar  Channel  program.   It  communicates  with  the 

--  Radar  Scheduler  and  Radar  Output  processes.   The  Radar  Channel  program 

--  uses  the  data  to  process  commands  for  the  SPY-1  radar. 


pragma  arithcheck(off ) ;  pragma  debug(off); 
pragma  enumtab(of f ) ;    pragma  rangecheck(off ) ; 

@  pragma  arithcheck(on) ;  pragma  debug~i(on)  ; 

@  oragma  ^numcab(on) ;    pragma  rangecheck(,on)  ; 


PACKAGE  tab4Q  13 

TYPE  CntrlWord  IS  RECORD 
rdr_xmsn_on         : 

adi  detect_enable    : 
sd!5_canx_cn        : 
chni_a_video        : 
cnnl_o_'-rideo        : 
freq_group_3ict 
rng_3calihg_r^nabie 
II _iubchni^lisaois 
t2_3ubcnni_disaDie 
i3_5ubchni_iisaoie 
t4_iUDchni~iisacie 
juocnni_weignt_enaDia 
cltr_lock_ops       : 
,:Itr_locK_e"rr       : 
END  RECORD: 


BOOLEAN; 
BOOLEAN ; 
BOOLEAN; 
BOOLEAN; 
BOOLEAN; 
300LSAN ; 
BOOLEAN ; 
BOOLEAN ; 
BOOLEAN : 
300LEAN : 
BOOLEAN : 
:  BOOLEAN 
BOOLEAN ; 
300LEAN ; 


TYPE  F re qG roupS elect  15  RECORD 


>ri_mode_a 
b_submode 
c_submode 
END  RECORD; 


INTEGER; 
INTEGER; 
INTEGER; 


TYPE  OaType  IS  RECORD 
cntrl_word 
freq_group_select 
data_block_code 

END  RECORD; 


CntrlWord; 

FreqGroupSelect; 

INTEGER; 


TYPE  ObType  IS  RECORD 

detectl_thrsld  :  INTEGER 
detect2_thrsld  :  INTEGER 
detect3_thrsld  :  INTEGER 
sdlb_thrsld    :  INTEGER 

END  RECORD; 


TYPE  OcType  IS  RECORD 

mnlb_thrsldl 

cvr_pulse  thrsldl 

satl_thrsTd 

sat2_thrsld 
END  RECORD; 


INTEGER 
INTEGER 
INTEGER 
INTEGER 


TYPE  OdType  IS  RECORD 

ratio_thrsld  :  INTEGER 
limit_thrsld  :  INTEGER 
cltr_thrsld   :  INTEGER 

END  RECORD; 

TYPE  OeType  IS  RECORD 
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comptr_lock  init  :  INTEGER; 

truncl_thrsld  :  INTEGER; 

trunc2_thrsld  :  INTEGER; 
END  RECORD; 

TYPE  OfType  IS  RECORD 

phsel_code  :  INTEGER; 

phse2_code  :  INTEGER; 

phse3_code  :  INTEGER; 

phse4_code  :  INTEGER; 
END  RECORD; 

TYPE  OgType  IS  RECORD 

fdbkl  :  INTEGER; 

fdbk2  :  INTEGER 

fdbkS  :  INTEGER 

fdbk4  :  INTEGER 
END  RECORD; 

TYPE  OhTvpe  IS  RECORD 

pril^mti  :  INTEGER; 

pri2_mti  :  INTEGER; 
END  RECORD; 


TYPE  OiType  IS  RECORD 
cntrl_bit 
iwl_l~start_time 
dwl_2~s tart  time 

2ND  RECORD: 


300LEAN: 
INTEGER: 
INTEGER; 


TYPE  OjType  IS  RECORD 

cntrl_bit  :  300LEAN: 

doc t  T  unblnk_s tart  :  INTEGER: 
subcEnI_freq_group   :  INTEGER; 

END  RECORD: 

TYPE  OkType  IS  RECORD 

cntrl_bit  :  BOOLEAN 

doct  l_unblnk_stop  :  INTEGER 

fixe3_atten_cntrl  :  INTEGER 

stc_cntrl  :  INTEGER 

END  RECORD; 

TYPE  OiType  IS  RECORD 

cntrl_bit  :  BOOLEAN 

doc t_2_unblnk_s tart  :  INTEGER 

xmit  freq  :  INTEGER 

rcvJFreq  :  INTEGER 

END  RECORD; 


TYPE  OmType  IS  RECORD 

cntrl_bit  :  BOOLEAN; 

doct_2_unblnk_stop  :  INTEGER; 

face  :  INTEGER; 

fore_beam_alarm_inhib:  INTEGER; 

cos_alphal_mn_array  :  INTEGER; 
END  RECORD; 

TYPE  OnType  IS  RECORD 

cntrl_bit  :  BOOLEAN; 

cltr  l_unblnk_start  :  INTEGER; 

aft_Beam_alert  inhib:  INTEGER; 

cos_alpha2_sdlb"_blnk_ary:  INTEGER; 
END  RECORD; 


TYPE  OoType  IS  RECORD 
cntrl_bit 

cltr  l_unblnk_start 
cos_Hetal_mn_array 


BOOLEAN 
INTEGER 
INTEGER 
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END  RECORD; 


TYPE  OpType  IS  RECORD 

cntrl_bit  :  BOOLEAN; 

cltr  2_unblk  strt    :  INTEGER; 

cos  Eeta2  sdlb  blnk  ary:  INTEGER; 
END  RECORD; 


TYPE  OqType  IS  RECORD 

cntrl_bit 

cltr_2_unblk_stop 

elev_sector 

dply_ctrl 

trk_num 
END  RECORD; 


BOOLEAN 
INTEGER 
INTEGER 
INTEGER 

INTEGER 


TYPE  OrTvpe  IS  RECORD 

::-:;_gai:e_strt  :  INTEGER' ,- 
doly_elev     :  INTEGER: 

END    RECORD; 

TYPE   OsType    IS    RECORD 
video_axtnc        : 

t    •    INTEGER 


aoiv 


vd 


iDiv_azim 
END    RECORD: 


INTEGER 


TYPE  DtTvpe  13  RECORD 
Jtmsb  :  INTEGER; 
otlsb  :  INTEGER: 

END  RECORD; 

TYPE  OtArrav  IS  ARRfiYQ 


TYPE  OccbT 
TYPE  Ptr.Oc 
TYPE  DccbT 

oa 

ob 

oc 

od 

oe 

o_f 

o 

oi 

°oi 

ol 
om 
on 
oo 
op 
oq 
o_r 

OS 

ot 

link 
END  RECORD 


v"C  a : 

:b  IS  ACCESS 

7pe  IS  RECORD 

OaType 

ObType 

OcType 

OdType 

OeType 

OfType 

OqType 

OhType 

OiType 

OiType 

OkType 

OiType 

OmType 

OnType 

OoType 

OpType 

OqType 

OrType 

OsType 

OtArray ; 

PtrOccb; 


.15)  OF  OtType 


ccbType 


occb:  PtrOccb; 

TYPE  OCCBPtrArray  IS  ARRAY(1..2)  OF  PtrOccb; 
occb_ptr:  OCCBPtrArray; 


END  tab40; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  23  Oct  86 

--  MODULE  TYPE:  data  buffer 

--  PURPOSE:  internal  data  structure 

—  NAME:  Output  Control  Channel  Buffer  ...TAB40.PKG 

--  This  interface  data  structure  is  a  buffer  between  the  Radar  Control 
--  program  and  the  Radar  Channel  program.   It  communicates  with  the 
--  Radar  Scheduler  and  Radar  Output  processes.   The  Radar  Channel  program 
--  uses  the  data  to  process  commands  for  the  SPY-1  radar. 

pragma  arithcheck(off ) ;  pragma  debug(off ) : 

praqma  enumtab(off )  ;    braqma  rangecheckt^off )  ■ 
"?  praqma  arithcheck(on)  ;  oragma  debug(on;,- 
■§  pragma  anumtao^on);    pragma  rangecheck(on) ; 

PACKAGE  30DY  :aD40  IS 


3EGIM 


occb_ptr(l) :=  NEW  OccbType; 
occb_ptr(2) :=  MEW  OccbType; 
occb_ptr(l )  ..linlc:=  null"; 
occb_ptr(2) .link:=  null; 


iND  :ao40 ; 
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APPENDIX  B 
GLOBAL  SOURCE  CODE 


--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  22  Oct  86 

—  MODULE  TYPE:  Global  data 

--  PURPOSE:  System's  Data  Structure  declarations 

--  NAME:  GLOBAL  DECLARATIONS .. .GLOBAL .LIB 

pragma  arithcheck(of f ) ;  pragma  debug(off ) • 
pragma  enumtab(ofr) ;    bragma  rangecneck(off ) 
@  pYagma  arithchecK(,on)  ;  pragma  deoug^cn;,- 
<a  pragma  enumcab(onj;    pragma  rangecheck^on; ,- 

PACKAGE  global  IS 

--SES  CONSTANTS 

numo_event:s :  CONSTANT  INTEGER  :=  23; 
buff_3ize:  CONSTANT  INTEGER  :=i0; 
infinity:  CONSTANT  INTEGER  :=  32000; 
numo  orocs:  CONSTANT  INTEGER  :=  21; 


—  nmr<* 


recess  identifiers 


a_pi 
c_pi 
b_pic 

d_pi 
a  pi 

£-Pi 

k_pi 

lji 
m_pi 
w_pi 

X-Pi 
h_pi 

o_pi 

P-Pi 

s_pi 
r_pi 
main 
idle 


a: 

d: 
d: 
d: 
O: 
d: 
d: 
d: 
d: 
d: 
d: 
d: 
d: 
d: 
d: 
d: 
d: 
d: 

_i 

i 


CONSTANT  INTEGER 
CONSTANT  INTEGER 


CONSTANT 
CONSTANT 


INTEGER 
INTEGER 


=  x 


CONSTANT  INTEGER 
CONSTANT  INTEGER 
CONSTANT  INTEGER 
CONSTANT  INTEGER 
CONSTANT  INTEGER 
CONSTANT  INTEGER 
CONSTANT  INTEGER 
CONSTANT  INTEGER 
CONSTANT  INTEGER 
CONSTANT  INTEGER 
CONSTANT  INTEGER 
CONSTANT  INTEGER 
CONSTANT  INTEGER 
CONSTANT  INTEGER 
d:  CONSTANT  INTEGER 
d:  CONSTANT  INTEGER 


o 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 
:=  19; 
;=  20; 


--event  count  identifiers,  reserved  event  count  identifiers:  0,1,2,6,20 


main  event_id: 
display_evc_rid : 
time_count_Id : 
idle  event_id: 
ea_iH:  CONSTANT 
ec_id:  CONSTANT 
eb_id:  CONSTANT 
ed_id:  CONSTANT 
ee_id:  CONSTANT 
ef_id:  CONSTANT 
ek_id:  CONSTANT 
el_id:  CONSTANT 
em_id:  CONSTANT 
ew_id:  CONSTANT 
ex_id:  CONSTANT 
eh  id:  CONSTANT 


CONSTANT 

CONSTANT 
CONSTANT 
CONSTANT 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 


INTEGER  : 

INTEGER 
INTEGER  ; 
INTEGER 

=  3 

=  4 

=  5 

=  7 

=  8 

=  9 

=  10 

=  11 

=  12 

=  13 

=  14 

=  15 


=  1; 

:=  2; 
=  6; 
=  20; 
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eo_id:  CONSTANT  INTEGER 

ei_id:  CONSTANT  INTEGER 

ep_id:  CONSTANT  INTEGER 

et_id:  CONSTANT  INTEGER 

es_id:  CONSTANT  INTEGER 

er  id:  CONSTANT  INTEGER 


=  16 
=  17 
=  18 
=  19 
=  21 
=  22 


--common  service  routines 

FUNCTION  clock  RETURN  INTEGER; 

FUNCTION  rand  RETURN  INTEGER; 

PROCEDURE  ipl; 

PROCEDURE  await(proc_id,event_id.event_value:  IN  INTEGER); 

PROCEDURE  advance (proc_id,event_id:  IN  INTEGER); 
FUNCTION  ticket  RETURN  INTEGER; 
PROCEDURE  disable; 
PROCEDURE  enable; 

--System's  Data  Objects 

TYPE  EveValArray  IS  ARRAY  (0 . .numb_events)  OF  INTEGER; 
event_val_cnt  : EveValArray; 

TYPE  process  IS  RECORD 


INTEGER 
INTEGER 
INTEGER 
INTEGER 


status 
context 

scunt 

event 
END  RECORD: 
TYPE  ProTabArray  IS  ARRAY  < 0 . .numb_procs )  OF  process: 


prcs_~oie 
[ND  glooai  .- 


Ov 


oTabArray; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  26  Nov  86 

--  MODULE  TYPE:  global  package  body 

--  PURPOSE:  to  define  common  service  routines 

--  NAME:  global  ...  GLOBAL. PKG 

pragma  arithcheck(off ) ;  pragma  debug(off ) ; 

pragma  enumtab(off ) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on) ; 
@  pragma  enumtab(on);    pragma  rangecheck(on) ; 

WITH  Longops , tabO , tabl , tab2 , tab7 ; 

PACKAGE  30DY  global  IS 

USE  Longops , cabO , tabi , tao2 , :ab7 ; 

--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  .AST  UPDATE :.'  1  Dec  86 

--  MODULE  TYPE:  common  service  routine 

--  PURPOSE:  generata  a  random  number 

--  NAME:  RAND  .  .  .csr5 

--  This  oseudo-random  numoer  jenarator  uses  the  :ongruence  algorithm 
—  io  generate  a  list  zf    random  numoers  with  a  period  approximately 
--  -equal  to  "t."  .  The  eauation  is  of  the  form: 
X(n+I)  =  nod   (A  T  1(11)  -  3)  Z) 

X:     INTEGER :=  -I; 

FUNCTION  rand  RETURN  INTEGER  IS 


INTEGER  :-  357 

INTEGER 

INTEGER 


=  31099: 


seed:  INTEGER  :-  19879; 
y:  Long_In eager; 

BEGIN 

IF  X=-l  THEN 
x:=  seed; 
END  IF; 

--  compute  the  random  number 
y:=  Ladd(Lmul(Lint(a),Lint(x)),Lint(b)); 
x:=L_to_int(Lmod(y,Lint(t))) ; 
RETURN  X; 
END  rand; 
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OWNER:  AEGIS  Modeling  Group 

DATE  OF  LAST  UPDATE:  30  Nov  86 

MODULE  TYPE:  external  initialization  routine 

PURPOSE:  initialize  the  priority  event  list  for  the  Radar  Scheduler  Model 

NAME:  Initialize  the  Radar  Event  Priority  List...csr6 

This  routine  initializes  the  Priority  Event  List  which  is  used  by  the 
Radar  Scheduler,  Search  Management  and  Track  Management  processes  to 
request  and  schedule  radar  dwells. 

PROCEDURE  ipl  IS 

i:  INTEGER: 

BEGIN 

for  i  in  l..max_pri  LOOP 

pri_lst(i) .status:-  false; 
pri~lst(i)  .b_pri.:=  i,- 
pri_lst(i) .c_pri:=  i; 
pri_lst(i) .ltX:=  0; 
pri_lst i) .slct_flg:=  false: 
pri~lst(  i)  .nxt  ■.=   i+1; 

IF  ((i<=8)  OR  ((i>=l.a)  AND  (i<=13))')  THEN 

pri  Lst(i)  .allwd  Ltx:-  100: 
2LSIF  (Ti>=14)  AND  (1<=21.) )  THEN 

pri  lst(i) .allwd  itx:  =  500; 
ELSI"F  (1=9)  THEN 

pri  Lst(i). allwd  ltx.:^  25; 
EESTF  1=22)  THEN 

ori  Lst(i)  .allwd  ltx.:  =  50; 
2L2E 

pri:_lst<  i)  . allwd_ltx':=  infinity; 
END  IE; 

IF  (  (i<io_enhnc;  OR  (i>22))  THEN 

pri_lst(i) .enhnc :=  false; 
ELSE 

pri_lst(i) .enhnc :=  true; 
END  IF; 

IF  ((i<=3)  OR  ((i>=10)  AND  (i<=13))  OR  (i>=23))  THEN 

pri_lst(i) .max_noaes :=  5 j 

pri_lst(i) .que_id:=  special_request ; 

pri_lst(i) .que_ptr .kind:=  special_request; 

pri_lst(i) .que_ptr. Snode :=  NEW  SearchNode; 

pri  lst(i) .que  otr. Snode. nxt :=  null; 
ELSIF  CU=4)  OR  ((i>=6)  AND  (i<=8))  OR  ((i>=14)  AND  (i<=21)))  THEN 

pri_lst(i) .max_nodes :=  5; 

pri_lst(i) .que_id:=  track; 

pri_lst(i) ,que_ptr .kind:=  track; 

pri_lst(i) .que_ptr .Tnode :=  NEW  TrackNode; 

pri_lst(i) .que_ptr. Tnode. info. p_trk:=  NEW  TrkFile; 

pri_lst( i) .que_ptr. Tnode . info. p_trk.beam_data :=  NEW  TrkData; 

pri  lst(i) .que  otr. Tnode .nxt :=  null; 
ELSIF  C\i=9)    OR  (i=22))  THEN 

pri_lst(i) .max_noaes :=  10; 

pri_lst(i ) .que_id:=  search; 

pri_lst(i) .que_ptr .kind:=  search; 

pri_lst(i ) .que_ptr .Snode :=  NEW  SearchNode; 

pri_lst(i ) .que_ptr. Snode . info :=  NEW  SrchData; 

pri_lst(i) .que_ptr .Snode. nxt :=  null; 
ELSE 

pri_lst(i} .max_nodes :-  2\ 

pri_lst(i ) ,que_id:=  missile; 

pri_lst( i) .que_ptr .kind:=  missile; 

pri_lst( i) .que_ptr. Tnode :=  NEW  TrackNode; 

pri_lst(i) .que_ptr .Tnode. nxt :=  null; 
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END  IF; 

END  LOOP; 

--reset  "nxt"  on  last  element  in  Priority  List  to  point  to  0 
pri_lst(max_pri) .nxt :=  0; 


--  assi 

pri_lst 

pri_lst 

pri_lst 

pri_lst 

pri_lst 

pri_lst 

pri_lst 

pri_lst 

pri_ 1st 

pri_lst 

pri_lst 

pri_ist 

pri_lst 

pri_lst 

pri_lst 

pri~lst 

pri^lst 

pr.i_lst 

pri~lst 

bri~lst 

pri_L3t 

ori_lst 

pri~lst 

pri_ls 

p  r  i~ 1 s  t 

pri_lst 

END  ipl; 


n 
1 
2 
3 
4 
5 
5 
7) 

a). 

9). 

10) 

ID 

12) 

13) 

14) 

15) 

16) 

17) 

13) 

19) 

(20 

(21) 

(22 


( 
( 

3t 


24) 
26  ) 


event  name 

.eventnm:= 

.eventnm:= 

.eventnm:= 

.eventnm:= 

.eventnm:= 

. eventnm := 

. aventnm := 

. eventnm := 

.eventnm:= 

eventnm 

eventnm 

eventnm 

eventnm 

eventnm 

eventnm 

aventnm 

eventnm 

eventnm 

aventnm 

eventnm 

aventnm 

aventnm 

aventnm 

aventnm 

aventnm 

aventnm 


s  to  each  ] 
"A-EVENT  ■ 
"B-EVENT  ■ 

"C-EVENT  ■ 
"D-EVENT  ■ 
"E-EVENT  ■ 
"F-EVEMT  ■ 
"G-EVEMT  ■ 
"H- EVENT  ■ 
"I -EVENT 
'  I— EVENT 
'K- EVENT 
'L-EVEMT 
'M-EVENT 
'M- EVENT 
'0- EVENT 
'?- EVENT 
'0- EVENT 
'R- EVENT 
"3- EVENT 
'T- EVENT 
■U- EVENT 
'V- EVENT 
•W-EVENT 
'M-EVENT 
"Y- EVENT 
"Z- EVENT 


iriority 

■  ECM  BURNTHROUGH" ; 

■  TARGET  DEFINITION"; 

■  SPECIAL  TEST"; 

■  ENGAGED  HOSTILE  TARGET"; 

■  OWN  SM-2  MISSILE  GUIDANCE"; 

■  PRE-ENGAGED  HOSTILE  TARGET"; 

■  HIGH  PRI  TRACK  TRANSITION"; 

•  HIGH  PRI  TRACK  CONFIRMATION" ; 

■  HORIZON  SEARCH" r 

-  SPECIAL  ECM  BURNTHROUGH"; 

-  SPECIAL  TARGET  DEFINITION"; 

-  SPECIAL  MANUAL  SCAM" ; 

-  SPECIAL  TARGET  ACQUISITION"; 

-  CONFIRMED  HOSTILE  TRACK"; 

-  ASSUMED  HOSTILE  TRACK"; 

-  UNEVALUATED  TRACK" ; 

-  CONTROLLED  FRIENDLY  TRACK" • 

-  TRACK  CONFIRMATION" ; 

-  TRACK  TRANSITION"  • 

-  ASSUMED  FRIENDLY  TRACK" ; 

-  CONFIRMED  FRIENDLY  TRACK" ; 

-  ABOVE  HORIZON  SEARCH" ; 

-  SPECIAL  ABOVE  HORIZON  SEARCH" 

-  SIMULATION  DWELL"; 

-  DIAGNOSTIC  DWELL"; 

-  DUMMY  DWELL"; 
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OWNER:  AEGIS  Modeling  Group 

DATE  OF  LAST  UPDATE:  24  Jun  86 

MODULE  TYPE:  common  service  routine 

PURPOSE:  simulates  a  real  time  millisecond  clock 

NAME:  clock  ...csr7 

This  common  service  routine  simulates  a  real  time  millisecond  clock, 
when  the  routine  is  invoked  the  variable  "time"  is  incremented  by 
one.  The  new  value  of  time  is  then  RETURNed  to  the  invoking  PROCEDURE 

time:  INTEGER; 

FUNCTION  clock  RETURN  INTEGER  IS 

BEGIN 

time:=time  +  1; 

RETURN  time; 
END  clock; 
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--  The  following  functions  and  procedures  are  only  stubs  for  testing 

PROCEDURE  await(proc_id,event_id,event_val:IN  INTEGER)  IS 
BEGIN 
null; 

END  await; 

PROCEDURE  advance (proc_id,event_id: IN  INTEGER)  IS 
BEGIN 

null  ; 
END  advance ; 

FUNCTION  ticket  RETURN  INTEGER  IS 
BEGIN 

RETURN  0; 
ZND  ticket; 

PROCZDURE  disaoie  IS 
BEGIN 
null; 

END  disable ; 

PROCEDURE  enable  IS 
BEGIN 

null ; 
END  enaoie: 

--  initialization 
BEGIN 

:ime:-  -I; 

END  giooai; 
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APPENDIX  C 
RADAR  SCHEDULER  SOURCE  CODE 


--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  29  Aug  86 

--  MODULE  TYPE:  Process  vers  6.0 

--  PURPOSE:  Model  the  Radar  Scheduler  Function 

--  NAME:  Radar  Scheduler  ...  RRCM.LI3 

--  The  Radar  Scheduler  selects  requested  beams  from  queues  generated 
—  by  the  Search  Management  and  Track  Management  functions.-  The 
--  selected  beams  are 'then  processed  ano  formatted  into  iwells.   The 
--  dwells  are  transmitted  to  the  Radar  Output  function  and  are  oacked 
--  into  the  Channel  Output  Suffer.   Seams  are  selected  for  dwell 
--  processing  oased  on   a  priority  scheme. 

pragma  arithcheck(off ) ;  pragma  debug(off) ; 

pragma  enumtab(off.) ;    pragma  rangecheck(off )  ; 
@  pragma  arithcheck(on) ;  pragma  debug ( on ) ; 
'?  pragma  anumtao(on);    pragma  r.angecheck(on) ; 


PACKAGE 


•cm  IS 


PROCEDURE  radar_scheduler; 
END  rrcm; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  2  Dec  86 

--  MODULE  TYPE:  Process  vers  6.0 

—  PURPOSE:  Model  the  Radar  Scheduler  Function 

--  NAME:  Radar  Scheduler  ...  RRCM.PKG 

--  The  Radar  Scheduler  selects  requested  beams  from  queues  generated 

--  by  the  Search  Management  and  Track  Management  functions.   The 

--  selected  beams  are  then  processed  and  formatted  into  dwells.   The 

--  dwells  are  transmitted  to  the  Radar  Output  function  and  are  packed 

--  into  the  Channel  Output  Buffer.   Beams  are  selected  for  dwell 

--  processing  based  on  a  priority  scheme. 

oragma  arithcheck(off ) ;  pragma  debug(off); 

pragma  enumcab(off ) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on); 
@  pragma  enumcab(on) ;    pragma  rangecheck(on) ■ 

WITH  Io , Util , global , tabO , tabl , tab2 , tab4 , tab7 , tab32 , tab40 , rsmO , rsm2 , 
rsm3 , rsm5 , rsm9 , rsmlO , rsml2 , rsml3 , rsml4; 

PACKAGE  BODY  rrcm  IS 

USE  Io , Util , global ,  tabO , tabl , tab2 , iab4 , tab  7 , :ab32 , iab40 . rsmO  ,  rsm2  , 
rsm3  ,  rsm"5  ,  rsm9  ,  rsmiO  ,  rsmi2  ,  rsml3  ,  rsmi4 : 

PROCEDURE  radar_3cheduler  IS 

1:  INTEGER :=  0; 
J :  INTEGER :'    2 ; 

--beam  selection  module  CONSTANTS 

rdrint:  constant  integer s=  21; 
srch_que:  CONSTANT  INTEGER :=  1; 
sr_que:  CONSTANT  INTEGER :=  2; 
srch_dwls:  CONSTANT  INTEGER:=  9; 
sr_dwls:  CONSTANT  INTEGER :=  2; 
rdr_rsrcs:  CONSTANT  INTEGER :=  100; 
trk  que:  CONSTANT  INTEGER :=  3; 
mssT  que:  CONSTANT  INTEGER :=  4; 
trk  Hwls:  CONSTANT  INTEGER :=  10; 
mssl_dwls:  CONSTANT  INTEGER :=  5; 

rru  :  INTEGER; 

sru  :  INTEGER; 

sra  :  INTEGER; 
tot_dwl_schd:  INTEGER; 

tot  dwls  :  INTEGER; 

srcH_sra  :  INTEGER; 

trk  sra  :  INTEGER; 

mssl_sra  :  INTEGER; 

sr_sra  :  INTEGER; 

hwc  :  boolean; 


et 

rtim 
oltim 
dltatim 


INTEGER 
INTEGER 
INTEGER 
INTEGER 


BEGIN 


Delete("RSOUT.Txt"); 

Create (Text/'RSOUT.Txt" ,Write_Only) ; 

Open(Text,"RSOUT.Txt" ,Write_Only); 

WHILE  (i  <  A_to_R.op_doct.mintvls)  LOOP 
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i:=  i  +  1; 
intvl_num:=  i; 

--  advance  the  radar  loop  event  counts 

advance (r_pid,es_id) ; 
advance (r_pid.et_id) ; 
rtim:=  clock();  '  --  from  csr7  in  global. pkg 

--  swap  external  dwell  buffers 
swap(buff_ptr,cm_ptr, j) ;   --  from  rsm2.pkg 

--  enhance  event  priorities 

enhance (et);        --  from  rsm3.pkg 

--  resvnchronization  module  never  written 
--  rsm4.pkg 

--  begin  beam  selection 

--  initialize  the  priority  list  traversal  constraints 

et:=  0; 

rru.-=  0; 

tot  dwl_schd:=  0; 

srcH_sra:=  srch_dwls; 

trk_sra:=  trk_dwls; 

sr_sra:=  5r_dwis; 

mssi  sra:=  mssl_dwls; 

tot_3wis:=  srch_dwls  +  trk_dwls  +  sr_dwls  +  mssl_dwls; 

--  traverse  the  Priority  Lis" 

od  L  :  =  i  ; 

WHILE  ((et  <  rdrint  )  AND  I rru  <  rdr_rsrcs)  AND 

(tot_dwl_schd  <  tot_dwls)  AND  (ppl  /=  0))  LOOP 

--  check  for  an  empty  queue 
IF  pri_lst(ppl) .status  THEN 

--  traverse  the  priority  event  queue 

--  initialize  the  event  queue  traversal  constraints 

sru:=  Of 

CASE  pri_Lst(ppl) .que_id  IS 

WHEN  search  =>  sra:=  srch_sra; 

WHEN  special_request  =>  sra:=  sr_sra; 

WHEN  track  =>  sra:=  trk_sra; 

WHEN  missile  =>  sra:=  mssl_sra; 
END  CASE; 

--  select  a  search  type  beam  or  a  track  type  beam 
CASE  pri_lst(ppl) .que_id  IS 

WHEN  search  |  special_request  => 

--traverse  the  search  event  queue 
sp:=  pri_lst(ppl) .que_ptr .Snode; 
WHILE  (sp  /=  null)  LOOP 

--  get  a  Radar  Event  node 

r:=  get_rect_node() ;   --  from  RSM5B 

--  insert  beam  information  into  the  node 
r  .srch^.dwl.ALL:=  sp.  info. ALL; 
r.beamid:=  r.srch_dwl.bid; 

--  format  the  selected  beams 

--  do  supplementary  processing 

--  rsm6  not  writen 

--  do  face  assignment 

--  rsm7  not  written 

--  radar  doctrine 

--  rsm8  not  writen 
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--  satisfy  the  hardware  constraints 
hw_constraint(pri_lst(ppl) .que_id, rru, r .dru,hwc) ; 

IF  hwc  THEN 

--  indicate  to  the  Priority  List  that  this 
--  event  has  been  scheduled 
pri_lst(ppl) .slct_flg:=  TRUE ; 

--  fill  the  external  table  module 
fill_ext_tab(buf f_ptr ,occb_ptr( j ) ,cm  Dtr, 

ptr_r_to_o("3)  ,r.ocb_data) ;  --  rsmlC 

--  insert  the  dwell  at  the  end  of  the  Radar 

--  Event  Control  Table  list 

llend(r , rect_ptr) ;   --  from  rsm5a.pkg 

--  load  the  evaluation  module 
--  rsmll  never  written 

--  update  the  used  resources 

IF  (pri_lst(ppl) .que_id  =  search)  THEN 

srch_sra.-=  srch_sra  -  1; 
ELSE 

sr_sra:=  sr_sra  -  1; 
END  I?: 

tot_dwl_schd:=  tot_dwl_schd  +•  1  • 
s  ru :  =  s  ru  f  1  ; 

ELSE 

--  hardware  constraints  have  not  be^n   satisfied 
free_rect_node(r) ;   --  from  rsm5c.pkg 

END  :f; 

--  get  next  event  in  search  or  special  request 

--queue 

sp:=  sp.nxt; 


END  LOOP; 

--traverse  the  search  event  queue 
tp:=  pri_lst(ppl) . queotr.Tnode; 
WHILE  (sp  /=  null)  LOOP 


--  get  a  Radar  Event  node 

r:=  get_rect_node( ) ;   --  from  rsm5b.pkg 

--  insert  beam  information  into  node 

r. trk_dwl.ALL:=  tp. info.p_trk.beam_data.ALL; 

r.beamid:=  tp. info. bid; 

--  format  the  selected  beam 

--  do  supplementary  processing 

--  rsm6  not  written 

--  do  face  assignment 

--  rsm7  not  written 

--  radar  doctrine  module 

--  rsm8  not  written 

--  satisfy  the  hardware  constraints 
hw_constraint(pri_lst(ppl) .que_id, rru,r .dru,hwc) ; 

IF  hwc  THEN 

--  indicate  to  the  Priority  List  that  this 
--  event  has  been  scheduled 
pri_lst(ppl).slct_flg:=  TRUE; 
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--  fill  the  external  table  module 
fill_ext_tab(buff_ptr,occb_ptr( j ) ,cm  otr , 

ptr_r_to_o(3)  ,r.ocb_data) ;  --  r:. 

--  insert  the  dwell  at  the  end  of  the  Radar 

--  Event  Control  Table  list 

llend(r , rect_ptr) ;   --  from  rsm5a.pkg 

--  load  the  evaluation  module 
--  rsmll  never  written 


update  the  used  resources 
' pri_lst(ppl) .que_id  = 
:rk_sra:=  trk_sra  -  1; 


IF  (pri_lst(ppl).que_id  =  track)  THEN 


ELSE 

mssl_sra:=  mssl_sra  -  1 ; 
END  IF; 

tot_dwl_schd:=  tot_dwl_schd  +  1; 
sru:=  sru  +  1; 

ELSE 

--  hardware  constraints  have  not  been  satisfied 
f ree_rect_node(r) ;   --  from  rsm5c.pkg 

END  IF; 

--  get  next  event  in  track  or  missile  queue 
tp:=  tp.nxt; 

END  LOOP; 

END  CASE; 

END  IF;    --  end  traverse  event  que  &  check  for  empty  que 

--  compute  time  elapsed 
elapsed_time(et,rtim) ;    --  from  rsml2.pkg 

--  point  to  next  priority  in  the  list 
ppl:=  pri_lst(ppl; .nxt; 

END  LOOP;      --  end  traverse  priority  list 

IF  ((intvl_num  MOD  A_to_R.op_doct.dply_rect)  =  0)  THEN 

dump;   --  from  rsml3 

Put("Completed  interval  :  ") ;Put(intvl_num) ;New_Line; 
END  IF; 

--  free  memory  for  next  interval 
free_memory(pool_ptr, rect_ptr) ;   --  from  rsml4.pkg 

END  LOOP;      --  end  do  one  interval 
Close(Text) ; 

END  radar_scheduler; 

END  rrcm; 
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--  OWNER: AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  23  Oct  86 

--  MODULE  TYPE:  local  data  structure  declarations  vers  4.0 

--  PURPOSE:  declare  Radar  Scheduler  local  data  structures 

--  NAME:  Radar  Scheduler  Local  Declarations  ...RSMO.LIB 

--  This  file  contains  all  data  structures  internal  to  the  Radar  Scheduler 
--  Process. 

pragma  arithcheck(off ) ;  pragma  debug(off); 

pragma  enumtab(of f) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on); 
@  pragma  enumtab(on) ;    pragma  rangecheck(on) ; 

WITH  tabl , tab2 , tab  7 , tab32 , tab40 ; 

PACKAGE  rsmO  IS 

USE  tabl,tab2,tab7,tab32,tab40; 

--beam  selection  module  CONSTANTS 

rdrint:  CONSTANT  INTEGER :=  21; 
srch_aue:  "CONSTANT  INTEGER:3  1; 
sr_aue:  CONSTANT  INTEGER:-  2; 
Srch  dwls:  CONSTANT  INTEGER:3  9; 
sr.dwls:  CONSTANT  INTEGER:3  2; 
rdr_rsrcs:  CONSTANT  INTEGER:3  100: 
trk  que:  CONSTANT  INTEGER :=    3; 
mssljaue:  CONSTANT  INTEGER:3  4; 
trk  awls:  CONSTANT  INTEGER:3  10; 
nnssl  awls:  CONSTANT  INTEGER:3  5; 


pp-1 :  INTEGER ; 
intvl_num : INTEGER ■ 


--Radar  Event  Control  table  node 


type  OcbData  IS  RECORD 

ocb_purp       :  INTEGER 

xmit_flg 

face_assign 

pri_mti 

doct_blnk_gte 

cltr_blnk_gte 

mis_up  com 

mis_ind*x 

xmit  freq_chnl 

rcv_Trec>  chnl 

subchnl  treq_grp:  INTEGER; 

phse_co3e       :  INTEGER 

fdbk_phsecode 

m j  r_a_mode 

b_submode 

c_submode 

freq_grp_slct 

dwl_strt  ctl 

detect_tHrslds 

trunc  thrslds 

dwl_i3x_num 

elev_sctr 

dply_azim 

dply_elev 

vid_extnt 

rge_trk_gte_strt 
END  RECORD; 


boolean 

INTEGER 
ARRAY ( 1 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 


INTEGER 
INTEGER 
INTEGER 
INTEGER 
boolean 
INTEGER 
ARRAY (1 
ARRAY (1 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER; 


.2)  OF  INTEGER; 


OF  INTEGER; 
OF  INTEGER; 
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See  TAB1.LIB 
See  TAB7.LIB 


type  RadEveConTab; 

type  RECTPtr  is  access  RadEveConTab; 

type  RadEveConTab  IS  RECORD 

srch  dwl      :  SrchDatPtr; 

trk_dwl       :  TrkDatPtr; 

ocb_data      :  OcbData; 

beamid        :  string(3); 

dru  :  INTEGER; 

nxt_event     :  RECTPtr; 
END  RECORD; 
--end  Radar  Control  Table  node  declaration 


sp :  SearchPtr; 
tp:  TrkPtr; 
r:  RECTPtr; 
rect_ptr:  RECTPtr, 
Dool_ptr:  RECTPtr 
ouff_ptr:  PtrOccb 
cm _ptr:  PtrRtoO; 


See  TAB1.LIB 

See  TAB2.LIB 


•-  See  TAB40.LIB 
■-  See  TAB32.LIB 


END  rsmO; 


106 


--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  30  Nov  86 

--  MODULE  TYPE:  Radar  Schedular  Module  vers  4.0 

--  PURPOSE:  Initialize  lists  and  variable  for  the  Radar  Schedular  Process 

--  NAME:  Radar  Schedular  Initialization  ...RSMO.PKG 

pragma  arithcheck(off ) ;  pragma  debug(off ) ; 

pragma  enumtab(off ) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on); 
@  pragma  enumtab(on);    pragma  rangecheck(on) ; 

WITH  tabl , tab2 , tab7 , tab32 , tab40 ; 

PACKAGE  BODY  rsmO  IS 

USE  tabl,tab2,tab7,tab32,tab40; 

--  initialization  module  constants 
>ool_length:  CONSTANT  INTEGER :=  22; 


p00l_lengtn:  CONSTANT  INTEGER := 

buff_pool_length:  CONSTANT :=  2; 


--  Procedure  make_pool  is  derived  from  PL1  RSM1A  module  (MAKE  POOL). 
--  This  procedure  creates  a  pool  of  available  Radar  Event  Control 
--  Table' nodes  (see  RSMO). 

PROCEDURE  make_?ool( FirstNode: IN  OUT  RECTPtr ;numb_nodes :IN  INTEGER)  IS 

count:  INTEGER; 

p,q:  RECTPtr  :=  MEW  RadEveConTab: 

BEGIN 

p .nxt  event :=  null; 
p.srcE  dwl:=  New  SrchData; 
p.trk_dwl:=  New  TrkData; 
p:=  FirstNode; 
p.ALL:=  FirstNode. ALL; 

FOR  count  IN  2. .numb_nodes  LOOP 

q:=  NEW  RadEveConTab; 

q.srch  dwl:=  New  SrchData; 

q.trk_3wl:=  New  TrkData; 

q.nxt_event :=  null; 

p.nxt_event :=  q; 

p.nxt_event.ALL:=  q.ALL; 

p:=  p.nxt_event; 
END  LOOP; 

END  make_pool; 
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--  This  procedure  is  derived  from  PL1  RSM1B  (CREATE  DWELL  BUFFER  POOLS). 
--  This  procedure  creates  two  circular  lists  for  each  of  the  common 
--  memory  interfaced  data  structures  (see  TABLE32  &  TABLE40)  which 
--  receive  the  formatted  dwells  from  the  Radar  Scheduler  Process. 

PROCEDURE  ex_buff_create(buffl:IN  OUT  OCCBPtrArray ; buff 2 :IN  OUT  ROPtrArray; 

length:  IN  INTEGER)  IS 

pl,ql :PtrOccb  :=  NEW  OccbType; 
p2,q2:PtrRtoO  :=  NEW  RtoO; 
Ctr,j:  INTEGER; 

BEGIN 

FOR  j  IN  1 . . 2  LOOP 
pl:=  buffl(j); 

pi. link :=  null; 

p2:=  buff2(j): 

p2.1ink:=  null; 

FOR  ctr  IN  L.lenath  LOOP 
ql:=  NEW  OccbType; 
ql.link:=  null*- 
pi. link :=  ql; 

q2:=  NEW  RtoO; 
q2.1ink:=  null; 
p2.1ink:=  a2; 

END  LOOP; 

--  create  circular  lists 

ql.link:=  buffl(j) • 

a2.1ink:=  buff2(j) ; 
END  LOOP; 

END  ex_buff_create; 
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BEGIN 

pool_ptr:=  NEW  RadEveConTab; 
pool_ptr.nxt  event :=  null; 
pool_ptr .srcH  dwl:=  NEW  SrchData; 
pool_ptr.trk_3wl:=  NEW  TrkData; 
make_pool(pool_ptr ,  pool_lengtn) ; 
buff_ptr:=  NEW  OccbType; 
buff_ptr . link:=  null; 


cm_ptr:=  NEW  RtoO- 
crnotr . link:=  null; 
ex "buff  create (occb 


ex_buff_create(occb_ptr ,ptr_r_to_o,buff_pool_length) ; 

sp:=  NEW  SearchNode; 
sp.info:=  NhW  SrchData; 

3D.nXt:=  null; 

tb:  =  NEW  TrackNode: 
tp.info.p_trk:=  NEW  TrkFiler 
tp.in£o.p_trk.beam_data:=  NEW  TrkData,- 
tb.nxt:=  null; 
r*:=  NEW  RadEveConTab; 
r.srch  dwl:=  MEW  SrchData; 
r.trk_3wl:=NEW  TrkData; 
r .nxt_event :=  null; 
rect_ptr:=  NEW  RadEveConTab: 
recrlptr • srch  dwls=  MEW  SrchData; 
recc_ptr . trk_lwl:=  MEW  TrkData; 
rect  ptr-nxt_event:=  null; 


END  rsmO ; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  30  Sep  86 

--  MODULE  TYPE:  internal  routine  for  the  Radar  Scheduler  vers  2.0 

--  PURPOSE:  swap  output  buffers  for  the  next  scheduling  intervial 

--  NAME:  SWAP...  RSM2.LIB 

--  This  module  maintains  the  pointers  to  the  two  non-current  dwell  buffers 
--  which  are  the  destination  of  the  formated  dwells  scheduled  during  the 
--  current  scheduling  intervial. 

pragma  arithcheck(off ) ;  pragma  debugCoff) ; 

pragma  enumtab(off ) ;    pragma  rangecheck(of f ) ; 
@  pragma  arithcheck(on) ;  pragma  debug ( on ) ; 
@  pragma  enumtab(on) ;    pragma  rangecheck(on) ; 

WITH  tab32,tab40; 

PACKAGE  rsm2  IS 

USE  tab32,tab40; 

PROCEDURE  swap (buff: IN  OUT  PtrOccb;cm:IN  OUT  PtrRtoO; index: IN  OUT  INTEGER); 

END  rsm2; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  30  Sep  86 

—  MODULE  TYPE:  internal  routine  for  the  Radar  Scheduler  vers  2.0 
--  PURPOSE:  swap  output  buffers  for  the  next  scheduling  intervial 
--  NAME:  SWAP...  RSM2.PKG 

—  This  module  maintains  the  pointers  to  the  two  non-current  dwell  buffers 
--  which  are  the  destination  of  the  formated  dwells  scheduled  during  the 
--  current  scheduling  intervial. 

pragma  arithcheck(off ) ;  pragma  debug(off'); 

pragma  enumtab(of f ) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on); 
@  pragma  enumtab(on);    pragma  rangecheck(on) ; 

WITH  tab32,tab40r 

PACKAGE  30DY  rsm2  IS 

USE  tab32,tab40; 

PROCEDURE  swaD(buff:IN  OUT  PtrOccb;cm:IN  OUT  PtrRtoO; index: IN  OUT  INTEGER) 
IS 

BEGIN 

IF  (index=2)  THEN 

index:-  I; 
ELSE 

index:-  2; 
END  IF; 

buff:=  occbjptr(index) ; 
cm:=  ptr_r_to_o ( index ) ; 

END  swap; 

END  rsm2; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  30  Sep  86 

—  MODULE  TYPE:  Radar  Scheduler  Module  vers  3.0 

--  PURPOSE:  enhance  and  dehance  priorities  of  events  in  the  Radar  Event 

--  Priority  List 

--  NAME:  enhance...  RSM3.LIB 

—  This  module  enhances  the  priorities  of  the  radar  events  as  listed  in 
--  the  Priority  List  if  certian  conditions  are  met.  The  conditions  are: 

1.  The  enhance  flag  must  be  set  to  true 

2.  The  ltx  value  must  be  greater  than  the  allwd_ltx  value 

pragma  arithcheck(off ) ;  pragma  debug(off ) ; 

pragma  enumtab(off ) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on); 
@  pragma  enumtab^on) ;    pragma  rangecheck(on) • 

PACKAGE  rsm3  IS 

PROCEDURE  enhance(elapsed_time:  IN  INTEGER); 

END  rsm3; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  30  Sep  86 

--  MODULE  TYPE:  Radar  Scheduler  Module  vers  3.0 

--  PURPOSE:  enhance  and  dehance  priorities  of  events  in  the  Radar  Event 

--  Priority  List 

--  NAME:  enhance...  RSM3.PKG 

pragma  arithcheck(off ) ;  pragma  debug(off); 

pragma  enumtab(off ) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on); 
@  pragma  enumtab(on);    pragma  rangecheck(on) ; 

WITH  tabO; 

PACKAGE  30DY  rsm3  IS 

USE  tabO; 

--  OWNER:  AEGIS  Modeling  GrouD 

--  DATE  OF  LAST  UPDATE:  26  Nov  86 

--  MODULE  TYPE:  Radar  Scheduler  Subroutine 

--  PURPOSE:  remove,  insert  and  reset  the  current  priorities  of  Priority 

--  List  Events 

--  NAME:  Remove  and  Insert  ...  RSM3A 

--  This  module  locates  a  request  event  node  in  bhe  orioritv  list, 

--  removes  it  from  its  current  priority,  cnen  locates  its  new  position 

—  in  che  priority  list,  and  inserts  it  thei 


>  *"f» 


PROCEDURE  ripi( curnt.  new_p:  IN  INTEGER)  IS 

O:  INTEGER :=  1; 

b4:  INTEGER :=  1; 
tempi ,  temp2 :  INTEGER ; 

BEGIN 

IF  (curnt  /=  new  d)  THEN 

--  remove  the  node  from  its  current  position 

WHILE  (pri_lst(p).c_pri  /=  curnt)  LOOP 

b4:=  p? 

p:=  pn_lst(p)  .nxt; 
END  LOOP; 
tempi :=  P; 

pri_lst(b4) .nxt:=  pri_lst(templ) .nxt; 
pri_lst(templ) .nxt:=  0; 

--  insert  the  node  at  the  new  priority 
b4^=  1; 

WHILE'  (pri_lst(p)  .c_pri  /=  new_jD)  LOOP 

b4:=  p? 

p:=  pri_lst(p) .nxt; 
END  LOOP; 
temp2 :=  p; 

pri_lst(b4) .nxt :=  tempi; 
pri_lst( tempi) .nxt:=  temp2; 

--  reset  all  current  priority  values 
tempi :=  0; 

WHILE '(p  /=  0)  LOOP 

tempi :=  tempi  +  1; 

pri_lst(p) .c_pri:=  tempi; 

p:=  pri_lst(p) .nxt; 
END  LOOP; 
END  IF; 

END  ripl; 
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--  This  module  enhances  the  priorities  of  the  radar  events  as  listed  in 
--  the  Priority  List  if  certian  conditions  are  met.  The  conditions  are: 

1.  The  enhance  flag  must  be  set  to  true 

2.  The  ltx  value  must  be  greater  than  the  allwd_ltx  value 

PROCEDURE  enhance (elapsed_time:  IN  INTEGER)  IS 

p:  INTEGER :=  1; 
new_pri:  INTEGER; 

BEGIN 

--  reset  the  value  of  ltx  for  all  events 

WHILE  (pri  lst(p).nxt  /=  0)  LOOP 
IF  prijlst(p) .slct_flg  THEN 

priT_lst  (p)  .  ltX:  =  0 ; 

pn_lst(p) .slct  flg:=  false; 
ELSE 

pri_lst(p) .ltx:=  ori_lst(p) .ltx  +  elapsed  time; 
END  IF; 

p:=  pri  Istfp) .nxt; 
END  LOOP; 

--  traverse  the  priority  list 

FOR  p  IN  Io_enhnc. .max_pri  LOOP 

--  look  onlv  for  events  which  can  be  enhanced 

IF  ( (pr£_lst(pj  .annnc;  AND  (prri_lst(p)  -status))  THEN 

--  is  eiaosed  time  more  than  allowed  time? 

IF  (pri_lst(p) .ltx  >  pri_lst(p)  .aliwd_ltx)  THEN 

--  current  priority  is  move  standard  enhancement  value 
--  but  below  che  lowest  enhancement  value 

IF  ((pri  lst(p).c_pri  <=  (pri_lst(p) .b_pri  -  4))  AND 
(prO-St(p)  .c_pri  >  lo_enhnc))  THEN 

new_pri:=  pri_lst(p) .c_pri  -  1 ; 
ELSE 

new _jpri:=  pri_lst(p)  .b_pri  -  4; 

--  do  not  enhance  past  the  lowest  enhancement  value 

IF  (new_pri  <  lo_enhnc)  THEN 
new_pri:=  lo_enhnc; 

END  IF; 
END  IF; 

--  insert  the  event  at  its  new  priority  in  the  Radar  Event 
--  Priority  List 

ripl(pri_lst(p) .c_pri,  new_pri);   --  from  rsm3a 
END  IF; 
END  IF; 
END  LOOP; 
END  enhance; 

END  rsm3; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  8  Dec  86 

--  MODULE  TYPE:  Radar  Scheduler  Subroutines 

—  PRUPOSE :  Support  the  Beam  Selection  process 

--  NAME:  Beam  Selection  Routines...  RSM5.LIB  vers  2.0 

--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  30  Aug  86 

--  MODULE  TYPE:  Radar  Scheduler  Subroutine 

--  PRUPOSE:  insert  a  node  at  the  end  of  a  linked  list 

—  NAME:  llend  . . .  RSM5A 

--  This  subroutine  has  two  input  parameters:  "q"  is  a  pointer  to  the 
--  node  which  is  to  be  inserted,  "s"  is  a  pointer  to  the  list  to  which 
--  the  node  is  to  be  inserted  at  the  end  of. 

--  OWNER:  AEGIS  Modeling  GrouD 

--  DATE  OF  LAST  UPDATE:  30  Aug  36 

--  MODULE  TYPE:  3eam  selection  subroutine 

--  PURPOSE:  assign  a  Radar  Event  Control  Node  from  a  pool  of  available 

--  nodes 

--  NAME:  Get  Rect  Node  ...  RSM5B 

--  This  module  locates  the  first  available  RECT  node  from  the  pool.  It 
--  removes  the  node  from  the  pool  and  passes  its  pointer  back  bo  the 
--  invoking  procedure. 

--  OWNER:  AEGIS  Modeling  GrouD 

—  DATE  OF  LAST  UPDATE:  20  Aug  36 

--  MODULE  TYPE:  Beam  Selection  subroutine 

--  PURPOSE:  return  an  unused  RECT  node  to  the  available  pool  of  nodes 

--  NAME:  Free  RECT  node  ...  RSM5C 

--  This  module  returns  an  unused  radar  eevent  control  node  to  the 
--  available  pool  of  radar  event  control  nodes. 

pragma  arithcheck(off ) ;  pragma  debug(off); 

pragma  enumtab(of f ) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on) ; 
@  pragma  enumtab(on);    pragma  rangecheck(on) ; 

WITH  rsmO; 
PACKAGE  rsm5  IS 

USE  rsmO; 

PROCEDURE  llend(q,s:  IN  OUT  RECTPtr); 

FUNCTION  get_rect_node  RETURN  RECTPtr; 

PROCEDURE  free_rect_node(p:  IN  OUT  RECTPtr); 

END  rsm5; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  8  Dec  86 

--  MODULE  TYPE:  Radar  Scheduler  Subroutines  vers  2.0 

—  PRUPOSE:  Support  the  Beam  Selection  process 

--  NAME:  Beam  Selection  Routines...  RSM5.PKG 

pragma  arithcheck(off ) ;  pragma  debug(of f ) ; 

pragma  enumtab(off ) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on); 
@  pragma  enumtab(on);    pragma  rangecheck(on) ; 

WITH  tabl,tab7,rsm0; 
PACKAGE  BODY  rsm5  IS 

USE  tabl , tab 7 , rsmO ; 

--  oointers  for  procedure/function  use  only 
p:  RECTPtr; 

--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  30  Aug  86 

--  MODULE  TYPE:  Radar  Scheduler  Subroutine 

--  PRUPOSE:  insert  a  node  at  the  end  of  a  linked  list 
--  NAME:  -lend  ...  RSM5A 

--  This  subroutine  has  two  input  parameters:  "q"  is  a  pointer  to  the 
--  node  which  is  co  be  inserted,  "s"  is  a  pointer  Co  the  list  to  which 
--  the  node  is  to  be  inserted  at  the  end  of. 

PROCEDURE  llend(q,S:  IN  OUT  RECTPtr)  IS 

BEGIN 

--  set  the  new  node's  pointer  to  null 
q.nxt_event  .-=  null; 

--  check  for  an  empty  list 
IF  (s  =  null)  THEN 

S:=  q; 
ELSE 

WHILE' (p.nxt_event  /=  null)  LOOP 

p:=  p.nxt_event; 
END  LOOP; 

--  insert  the  new  node  at  the  end  of  the  list 
p.nxt_event:=  q; 
END  IF; 

END  llend; 
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OWNER:  AEGIS  Modeling  Group 

DATE  OF  LAST  UPDATE:  26  Nov  86 

MODULE  TYPE:  Beam  selection  subroutine 

PURPOSE:  assign  a  Radar  Event  Control  Node  from  a  pool  of  available 

nodes 

NAME:  Get  Rect  Node  ...  RSM5B 

This  module  locates  the  first  available  RECT  node  from  the  pool.  It 
removes  the  node  from  the  pool  and  passes  its  pointer  back  to  the 
invoking  procedure. 

FUNCTION  get_rect_node  RETURN  RECTPtr  IS 

BEGIN 

I?  (pooljptr  =  null)  THEN 

pool__ptr:=  NEW  RadEveConTab ; 

oooi_ptr .srch^iwi:^  NEW  SrcnData; 
pooi_pcr. trk_awl:=  NEW  TrkData,- 
END  IF; 

--  set  p  to  pool_ptr  then  relink  the  list 

D:=  DOOlJptr; 

pool"_pT:r :-  pool_ptr  .nxt_event  ,- 
o.nxt  avenif:-  null; 

RETURN  o; 
END  ast_rect_node : 
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--  OWNER:  AEGIS  Modeling  Group 

—  DATE  OF  LAST  UPDATE:  2  Dec  86 

--  MODULE  TYPE:  Beam  Selection  subroutine 

--  PURPOSE:  return  an  unused  RECT  node  to  the  available  pool  of  nodes 

--  NAME:  Free  RECT  node  ...  RSM5C 

--  This  module  returns  an  unused  radar  event  control  node  to  the 
--  available  pool  of  radar  event  control  nodes. 

PROCEDURE  free_rect_node(q:  IN  OUT  RECTPtr)  IS 

BEGIN 

--  set  link  to  null 
q_. nxt_event :.-  null; 

--  insert  the  node  at  the  and  of  the  node  oool  list 
IF  (pool_ptr  =  null)  THEN 

pooi_ptr:=  a; 
ELSE" 

p:=  OOOl_ptr; 

WHILE  (p.nxt_event  /=  null)  LOOP 
o:=  p.nxt_avent: 

END  'LOOP ; 

--  insert  unused  node 

p.nxfc  event:.-  a; 
END  "IF; 

END  free_rect_node ; 

BEGIN 

--  initialize  pointer  one  time  to  avoid  reinitiaization  every 
--  time  procedure/ function  is  called. 
p:=  NEW  RadEveConlab ; 

END  rsm5 ; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  30  Sep  86 

—  MODULE  TYPE:  internal  radar  scheduler  routine  vers  2.0 

--  PURPOSE:  ensure  dwells  satisfy  the  hardware  constraints 

--  NAME:  hw_constraint  ...  RSM9.LIB 

--  For  test  purposes  this  routine  assigns  a  fixed  percentage  of 

--  the  Radar  Resources  available  to  the  current  beam  being  formatted. 

pragma  arithcheck(off ) ;  pragma  debug(off) ; 

pragma  enumtab(off ) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on); 
d  pragma  enumtab(on);    pragma  rangecheck(on) ; 

WITH  tabO; 
PACKAGE  rsm9  IS 

USE  tabO; 

PROCEDURE  hw_constraint(id:IN  QueType ?  rru,dru:IN  OUT  INTEGER; 

hwc:O0T  BOOLEAN) ; 

END  rsm9 ; 


119 


--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  30  Sep  86 

--  MODULE  TYPE:  internal  radar  scheduler  routine  vers  2.0 

--  PURPOSE:  ensure  dwells  satisfy  the  hardware  constraints 

--  NAME:  hw_constraint  ...  RSM9.PKG 

--  For  test  purposes  this  routine  assigns  a  fixed  percentage  of 

--  the  Radar  Resources  available  to  the  current  beam  being  formatted. 

pragma  arithcheck(of f ) ;  pragma  debug(off ) ; 

pragma  enumtab(off ) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on); 
@  pragma  enumtab(on);    pragma  rangecheck(on) ; 

WITH  tabO; 

PACKAGE  BODY  rsm9  IS 

USE  tabO; 

PROCEDURE  hw_constraint(id:IN  QueType ;  rru,dru:IN  OUT  INTEGER; 

hwc:OUT  BOOLEAN)  IS 

srch_pcnt:  CONSTANT  INTEGER :=  3; 
sr  ocnt:  CONSTANT  INTEGER:^  6: 
trk  ocnt:  CONSTANT  INTEGER:-  7; 
mssllpcnt:  CONSTANT  INTEGER:=  7; 

percent:  INTEGER: 

BEGIN 

--  determine  correct  percent  of  resource  for  type  queue 

CASE  id  IS 

WHEN  search  =>  percent :=  srch_pcnt; 

WHEN  soecial_reauest  =>  oercent:=  sr_pcnt; 

WHEN  tracK  =>  pe'rcem::=  trkjpcnt; 

WHEN  missile  =>  percent :=  mssl_pcnt; 
END  CASE; 

rru:=  rru  +  percent; 

--  are  the  hardware  constraints  satisfied  ? 

IF  (rru  <  100)  THEN 

dru:=  100  -  rru; 

hwc:=  true; 
ELSE 

rru:=  rru  -  percent; 

hwc:=  false; 
END  IF; 

END  hw_constraint; 

END  rsm9; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  30  Sep  86 

--  MODULE  TYPE:  internal  radar  scheduler  routine  vers  2.0 

--  PURPOSE:  output  selected  and  formatted  dwells 

--  NAME:  fill  external  tables  ...  RSM10.LIB 

--  This  module  fills  the  two  common  memory  interface  dwell  buffers 
--  with  the  data  on  the  formatted  dwells.  The  buffers  are  double 
--  buffered  circularly  linked  lists.  Each  time  this  module  is  executed 
--  the  pointers  are  advanced  to  the  next  node  in  the  list. 

pragma  arithcheck(off ) ;  pragma  debug(off) ; 

pragma  enumtab(off ) ;    pragma  rangechecK(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug ( on ) ; 
@  pragma  er.umcaoi  on;  ,-    pragma  rangecneck(on)  ; 

WITH  tab3 2 , tab40 , r smO ; 

PACKAGE  rsmlO  IS 

USE  tab32, tab40,rsm0; 

PROCEDURE  fill_ext_tab(pl,p2:IN  OUT  PtrOccb :p3 . p4 :IN  OUT  PtrRtoO; 

pr  :TN  OcbData)  ; 

END  rsmlO: 
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OWNER:  AEGIS  Modeling  Group 

DATE  OF  LAST  UPDATE:  30  Sep  86 

MODULE  TYPE:  internal  radar  scheduler  routine 

PURPOSE:  output  selected  and  formatted  dwells 

NAME:  fill  external  tables  ...  RSM10.PKG 


vers  2.0 


--  This  module  fills  the  two  common  memory  interface  dwell  buffers 
--  with  the  data  on  the  formatted  dwells.  The  buffers  are  double 
--  buffered  circularly  linked  lists.  Each  time  this  module  is  executed 
--  the  pointers  are  advanced  to  the  next  node  in  the  list. 

pragma  arithcheck(off ) ;  pragma  debug(off); 

pragma  enumtab(off) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on) ; 
@  pragma  enumcab(on) ;    pragma  rangecheck(on) ; 

WITH  tab32 , tab40 , rsmO ; 

PACKAGE  BODY  rsmlO  IS 

USE  tab32, caD40,rsm0; 

PROCEDURE  fill_ext_tab(pl.,p2:IN  OUT  PtrOccb  ;o3  ,p4  :IN  OUT  PtrRtoO; 

or: IN  OcbData)  IS 


BEGIN 

IF  ((pi  /=  oZ)    AND  (p3  /=  p4))  THEN 
pi :=  Dl . link; 

bi:^  b3. link ; 
END  IF; 


■-  fill  channel  buffer  structure 


pl..oa 
p  1 .  om 
pi  .oh 
pi  .oh 
pl.ot 
pl.ot 
pl.ol 
pl.ol 
pl.oj 
pi  .o_ 
pl.og 
pi  .oa 
pl.oi 
pi  .ob 
pi  .ob 
pi  .ob 
pi  .oe 
pi  .oe 
pl.oq 
pi  .OS 
pi  .0_ 
pi  .OS 


cntrl  vord.rdr 


:ace:-  pr 
pril_mti 
.pri2_mti 


m.otlsb 
(1) .otmsb 


race 


_xmsn_on:= 

_assign: 
pri_mtii 1) 
i_mti(2) 


pr..xmit_f.lg; 


:a  chnl; 
rcv_f req_cnnl ; 


pr.pr: 

pr.mis_up  com; 

pr  .mis^.in3x; 
•xmit   freq:=  pr.xmit_fre< 
. rcv_Treq:=  pr. 

. subchnl_f req_group :=  pr .subchnl_freq_grp; 
f .phsel_code :=  pr.phse_code; 
. fdbkl:=  pr . fdbk_pnsecode; 

.cntrl_word.  freq_group_slct  :=  pr.  f  rec;  grp_slct; 
.dwl_l_start_time :=  pr. detect  thrslds(l); 
.detectl_thrsld:=  pr .detect_tHrslds(l> 
.detect2_thrsld:=  pr .detect_thrslds( 2\ 
.detect3_thrsld:=  pr. detect  thrslds(3' 
. truncl_thrsld:=  pr . trunc_tHrslds(l) ; 
. trunc2_thrsld:=  pr . trunc_thrslds(2) ; 
.elev_sector :=  pr.elev_sctr; 
.dply_azim:=  pr .dplvazim; 
r .dply_elev:=  pr .dply_elev; 
. video_extnt :=  pr . rge_trk_gte_strt; 


--  fill  R_to_0  Table  structure 

p3 .dwl_data.mode :=  pr.mjr_a_mode; 
p3  .dv;l_data.  face  :=  pr .  face_assign; 
p3.dwl_data.sub_mode(l) :=  pr .b_submode; 
p3.dwl_data.sub_mode(2) :=  pr.c  submode; 
p3.dwl_data.dwl_idx:=  pr.dwl_i3x  num; 
p3.dwl_data.beam_purpose  :=  pr  .ocb"  ourp; 
p3.dwl_data.dwl_itart_idx:=  pr .dwT_strt_ctl; 
p3.dwl_data.doct_unblnk  gates :=  pr.doct  blnk  gte; 
p3 . dwl_data . clutter_unblnk_gates :=  pr . cltr_blnk_gte ; 
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END   fill_ext_tab; 
END   rsmlO; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  21  Aug  86 

--  MODULE  TYPE:  internal  Radar  Scheduler  routine  vers  2.0 

--  PURPOSE:  compute  scheduling  interval  elapsed  time 

--  NAME:  Elapsed  Time  ...  RSM12.LIB 

--  This  module  is  designed  to  compute  the  amount  of  time  the  Radar 
--  Scheduler  has  spent  selecting  a  beam  from  the  current  requested 
--  event  queue.  The  routine  swaps  the  old  real  time  value  for  the 
--  current  real  time  value  (in  milliseconds)  and  then  computes  the 
--  new  value  of  the  real  time  and  updates  the  elapsed  time. 

pragma  arithcheck(off ) ;  pragma  debug(of f ) ; 

pragma  enumtab(of f ) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on) ; 
@  pragma  enumtab(on);    pragma  rangecheck(on)  ,- 

PACKAGE  rsml2  IS 

PROCEDURE  elapsed_time(et,rtim:  IN  OUT  INTEGER); 

END  rsml2; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  21  Aug  86 

--  MODULE  TYPE:  internal  Radar  Scheduler  routine 

--  PURPOSE:  compute  scheduling  interval  elapsed  time  vers  2.0 

--  NAME:  Elapsed  Time  ...  RSM12.PKG 

--  This  module  is  designed  to  compute  the  amount  of  time  the  Radar 
--  Scheduler  has  spent  selecting  a  beam  from  the  current  requested 
--  event  queue.  The  routine  swaps  the  old  real  time  value  for  the 
--  current  real  time  value  (in  milliseconds)  and  then  computes  the 
--  new  value  of  the  real  time  and  updates  the  elapsed  time. 

pragma  arithcheck(off ) ;  pragma  debugCoff ) ; 
pragma  enumtab* off ) ;    pragma  rangecheck(off ) • 
@  p'ragma  arithcheck(on) ;  pragma  debugt,oni 


i  - 


?     pragma    anumcatx  on;  ;  pragma   rangecnecic(on)  ; 

WITH   giobai; 

PACKAGE  3CDY  rsml2  IS 

USE  global; 

PROCEDURE  elapsed_time(e.t,rtlm:  IN  OUT  INTEGER)  IS 
oitim:  INTEGER; 

BEGIN 

oItim:-=  rtinv; 

rtim:-  clock();      --  riocx  from  csr7  in  giobai 

et:=  et  -  rtim  -  oltim; 

END  eiapsed_time; 

END  rsml2; 
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--  OWNER:  AEGIS  MODELLING  GROUP 

--  DATE  OF  LAST  UPDATE:  30  Sep  86 

--  MODULE  TYPE:  Internal  Radar  Scheduler  routine  vers  2.0 

--  PURPOSE:  Print  out  the  results  of  the  latest  scheduling  interval 

for  analysis 
-~  NAME:  Dump  ...  RSM13.LIB 

--  This  routine  prints  out  the  information  on  the  radar  request  queues 
--  and  the  scheduled  dwells  for  the  current  interval.  The  information 
--  printed  consists  of: 

1.  Requested  Beam  Listing 

a.  The  name  of  the  Event  whose  queue  is  being  printed 

b.  The  identification  code  of  the  requested  beam 

c.  The  requested  beam's  position  within  the  queue 

2.  Scheduled  Dwell  Listing 

a.  The  scheduled  dwell' s  unique  identification  code 

b.  The  amount  of  Radar  Resources  remaining  after  "he 
scheduling  of  the  dwell  -  expressed  as  a  percentage 

c.  The  index  into  "he  current  interval's  Radar  Event 
Control  Table 

pragma  arithcheck(off ) ;  oraqma  debug(off ) ; 
pragma  enumtab(ofx) ;    oragma  rangecheck.( off ) ■ 

3  oragma  arithcheck(  on;  ,-  oraqma  deouq^on); 

@  pragma  ^numtaoi  on)  ;    pragma  cangecheck(on) ; 

WITH  to; 

PACKAGE    rsml3    IS 

USE    Io; 
Text:    .Tiie; 

PROCEDURE    lump: 

END   rsm!3; 
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--  OWNER:  AEGIS  MODELLING  GROUP 

--  DATE  OF  LAST  UPDATE:  26  Nov  86 

--  MODULE  TYPE:  Internal  Radar  Scheduler  routine  vers  2.0 

--  PURPOSE:  Print  out  the  results  of  the  latest  scheduling  interval 

for  analysis 
--  NAME:  Dump  ...  RSM13.PKG 

--  This  routine  prints  out  the  information  on  the  radar  request  queues 
--  and  the  scheduled  dwells  for  the  current  interval.  The  information 
--  printed  consists  of: 

1.  Requested  Beam  Listing 

a.  The  name  of  the  Event  whose  queue  is  being  printed 

b.  The  identification  code  of  the  requested  beam 

c.  The  requested  beam's  position  within  the  queue 

2.  Scheduled  Dwell  Listing 

a.  The  scheduled  dwell ' s  unique  identification  code 

b.  The  amount  of  Radar  Resources  remaining  after  the 

c.  The  index  to  the  current  interval's  Radar  Event 
Control  Table 

pragma  arithcheck(off ) ;  pragma  debug(off ) ■ 

pragma  enumtab(off ) ;  pragma  rangecheck(of f ) ; 

f?  p"ragma  arithcheck(off ) ;  pragma  debug(off); 

?  pragma  enumtab(off ) ;  pragma  rangecheck^off ) ; 

WITH  tabO  ,  tabl .  cab2  ,  rsmO  ,  lo ,  Util  ,- 

PACKAGE  BODY  rsmi3  15 

USE  laoO . taol , "ao2 . rsmO , lo , Utii; 


dsh:  string(55) :=" 

sptr:  SearchPtr; 
tptr:  IrkPtr,- 

PROCEDURE  dump  IS 

Ctr:  INTEGER :=  1; 
start ,ctn,i:  INTEGER; 


BEGIN 


Put (Text, REQUESTED  BEAMS  FOR  SCHEDULER  INTERVAL:  "); 
Put(Text,intvl_num,5) ;  New_Line(Text) ; 
Put(Text,dsh) ;  New_Line(Text) ; 
WHILE  (ctr  /=  0)  LOOP 

Put(Text,pri_lst(ctr) .eventnm) ;  New_Line(Text) ; 

IF  pri_lst(ctr). status  THEN 

Put(Text,"BEAM  ID       "); 
i:=  0; 

CASE  pri_lst(ctr) .que_id  IS 

WHEN  search  |  special  request  => 

sptr:=  pri_lst(ctrr)  .que_ptr .Snode ; 
WHILE  ((i  <  10)  AND  (sptr  /=  null))  LOOP 

i:=  i  +  1; 

Put(Text,sptr.info  .bid);  Put(Text,"  "); 

sptr:=  sptr.nxt; 
END  LOOP; 

WHEN  track  |  missile  => 

tptr :=  pri_lst(ctr) . que_ptr .Tnode; 
WHILE  ((i  <  10)  AND  (tptr  /=  null;)  LOOP 
i:=  i  +  1; 
Put(Text, tptr. info  .bid);  Put(Text,"  "); 
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tptr:=  tptr.nxt; 
END  LOOP; 

END  CASE; 

New  Line (Text) ; 
PutTText, "QUEUE  POSIT   "); 
FOR  ctn  IN  l..i  LOOP 
Put(Text,ctn,4) ; 
END  LOOP; 

New  Line (Text) ; 

PutTText, dsh) ;  New_Line(Text) ; 

ELSE 

?ut(Text,"  NO  REQUESTS  THIS  INTERVAL"); 

New_Lme(Text)  ;  ?ut(Text ,dsh)  ;  New_Lme(Text)  ; 
END  IF; 

ctr:=  pri_lst(ctr) .nxt; 

END  LOOP; 

Mew  Line (Text) • 

PutTText, "SCHEDULED  DWELLS  FOR  SCHEDULER  INTERVAL:  "); 

Put  ( Text ,  intvl_num ,  z  )  ;  Mew_line  ( Text )  ; 

Put ; Text , dsn ) ;  Mew_Line ( Text) ; 

rptr:=  rect_ptr,- 

start :=  1; 

WHILE  (rptr  /=  null)  LOOP 
p:=  rptr; 

1:=  0'; 

Put  (Text. ''BEAM  ID       "); 

WHILE  ((i  <  10)  AND  (p  /=  null))  LOOP 

1:=  1  +  1; 

Put(Text,p.beamid);  Put(Text,"  "); 

p:=  p.nxt_event; 
END  LOOP; 
New  Line (Text) ; 
PutTText, "RESOURCES    "); 
i:=  0; 
p:=  rptr.- 
WHILE  ((l  <  10)  AND  (p  /=  null))  LOOP 

i:=  i  +  1; 

Put(Text,p.dru,4) ; 

p:=  p.nxt_event; 
END  LOOP; 
New  Line (Text) ; 
PutTText, "DWELL  #      "); 
FOR  ctn  IN  start. . (start  +  i  -  1)  LOOP 

Put(Text,ctn,4) ; 
END  LOOP; 
New  Line (Text) ; 

PutTText, dsh) ;  New_Line(Text) ; 
IF  (p  /=  null)  THEN 

rptr:=  p; 

start:=  start  +  i; 
ELSE 

rptr:=  null; 
END  IF; 

END  LOOP; 

Put(Text,dsh) ;  New_Line(Text) ;  New_Line(Text) ; 


END  dump; 
BEGIN 
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--  initialize  working  pointers  one  time  to  avoid  reinitialization 
each  time  procedure  is  invoked. 


sptr 

tptr 
rptr 


=  NEW  SearchMode; 
=  NEW  TrackMode; 
=  NEW  RadEveConTab; 


p:=  NEW  RadEveConTab; 
END  rsm!3; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  29  Aug  86 

--  MODULE  TYPE:  internal  Radar  Scheduler  routine  vers  2.0 

--  PURPOSE:  free  memory  for  the  next  scheduling  interval 

--  NAME:  Free  Memory  ...  RSM14.LIB 

—  This  module  traverses  the  available  RECT  pool  list  and  inserts  the 
--  current  Radar  Event  Control  Table  list  at  the  end  of  the  pool. 

pragma  arithcheck(off ) ;  pragma  debug(off ) ; 

pragma  enumtab(off ) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on) ; 
@  pragma  enumtab(on);    pragma  rangecheck(on) ; 

WITH  rsmO; 

PACKAGE  rsml4  IS 

USE  „-sm0  ; 

PROCEDURE  £ree_memory(pool_ptr,rect_ptr:IN  OUT  RECTPtr) ; 
END  rsml4; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  29  Aug  86 

--  MODULE  TYPE:  internal  Radar  Scheduler  routine  vers  2.0 

--  PURPOSE:  free  memory  for  the  next  scheduling  interval 

--  NAME:  Free  Memory  ...  RSM14.PKG 

--  This  module  traverses  the  available  RECT  pool  list  and  inserts  the 
—  current  Radar  Event  Control  Table  list  at  the  end  of  the  pool. 

pragma  arithcheck(off ) ;  pragma  debug(off); 

pragma  enumtab(off) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on) ; 
@  pragma  enumtab(on);    pragma  rangecheck(on) ; 

WITH  rsmOr 

PACKAGE  BODY  rsml4  IS 

USE  rsmO; 

--  pointer  for  procedure  use  only 
p:  RECTPtr; 

PROCEDURE  free_memory(pooi_ptr,rect_ptr:IN  OUT  RECTPtr)  IS 

3EGIN 

IF  (pool_ptr  =  null)  THEN 
pooi_ptr:=  rectjptr; 
r ec  t_p  t  r  •.  =  null  ; 
ELSE 

o.-=  oool_ptr- 

WHILE  (p.nxtr_event  /=  null)  LOOP 

p:=  p.nxt"  event; 
END  LOOP; 

p.nxt_event :=  recc_ptr: 
rect  ocr:=  null; 
END  IF; 
END  free_memory; 

BEGIN 

--  initialize  working  pointer  one  time  to  avoid 

--  reinitialization  each  time  procedure  is  invoked. 

p:=  NEW  RadEveConTab; 

END  rsml4; 
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APPENDIX  D 
TEST  HARNESS  SOURCE  CODE 


--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  24  Sep  86 

--  MODULE  TYPE:  Display  Subroutine  vers  2.0 

--  PURPOSE:  Operator  Interface 

--  NAME:  Operator  Interface  Module  ...  SADM1.LIB 

--  This  module  orovides  the  user  of  the  Radar  Scheduler  Test 
--  Harness  (SPY.COM)  with  the  ability  to  alter  some  of  the 
--  major  program  parameters  prior  to* execution  of  the  program 
--  with  out  having  to  alter  the  source  code,  recompile,  and 
--  link  the  program. 

pragma  arithcheck(off ) ;  pragma  debug(off) ; 

pragma  enumtab(of f ) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on) ; 
@  pragma  enumtab(on) ;    pragma  rangecheck(on) ; 

PACKAGE  sadmi  IS 

PROCEDURE  oim(numtrks,nummtvls,skipintvls :  OUT  INTEGER); 

END  sadml ; 
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--  OWNER:  AEGIS  Modeling  Group 

—  DATE  OF  LAST  UPDATE:  24  Sep  86 

--  MODULE  TYPE:  Display  Subroutine  vers  2.0 

--  PURPOSE:  Operator  Interface 

--  NAME:  Operator  Interface  Module  ...  SADM1.PKG 

--  This  module  provides  the  user  of  the  Radar  Scheduler  Test 

—  Harness  (SPY.COM)  with  the  ability  to  alter  some  of  the 

--  major  program  parameters  prior  to  execution  of  the  program 
--  with  out  having  to  alter  the  source  code,  recompile,  and 
--  link  the  program. 

pragma  arithcheckfoff ) ;  pragma  debug(off); 

pragma  enumtab^off ) ;    pragma  rangecheck( of f ) ; 
@  p'ragma  arithchecx(on)  ;  pragma  deoug(on)  ; 
@  pragma  enumtabion/,-    pragma  rangecheck(on)  ; 

WITH  Util"; 

PACKAGE  30DY  sadml  IS 

USE  Util; 

PROCEDURE  oim(niimtrks,numintvl"s,skipintvls:   OUT  INTEGER)    IS 


astrklS:  CONSTANT  STRING:-  "***************"  . 
^paceiO:  CONSTANT  STRING.-: ■=  " 

BEGIN 

Pufcf  astrklS.);  Put("       AEGIS  AN/SPY.l-A       "); 

?ut( astrklS) ;  Mew  Line; 

Put(astrkl5j;  Putt"    RADAR  SCHEDULER  PROGRAM    "; 
Putt  astrklS ) ;  New  Line ; 

Put  (  astrklS  )  :  PutTastrkl5") ;  Put(astrkl5) ;  Put;  astrklS)  • 
New  Line.-;  New_Line;  lew  Line-;  Mew_Line; 
PutT"Input  the  number  or  tracks  to  be  initialized;."); 
New  Line;  New_Lme;  Put(spacelO)  ; 

PutT"NUMBER  OF  TRACKS  --->  ");  Get (numtrks) ;  New_Line; 
New  Line;  New_Line; 

PutT"Input  the  number  of  scheduling  intervals  to  be  run."); 
New  Line,-  New_Line,-  Put(spacelO)  ; 
PutT"NUMBER  OF  INTERVALS  --->  ");  Get (numintvls) ; 
New  Line ;  New  Line ;  New  Line ; 

PutX"Define  tEe  interval  display  delay  period."); 
New  Line;  New_Line;  Put(spacelO) ; 

PutT"SKIP  INTERVALS  --->  fl);  Get (skipintvls) ;  New_Line; 
New  Line;  New_Line;  New_Line; 

PutTspacelO);  Put(spacelO) ;  Put ("BEGIN  EXECUTION"); 
New_Line ; 
END  oim; 


END  sadml; 
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OWNER:  AEGIS  MODELING  GROUP 

DATE  OF  LAST  UPDATE  :  31  AUG  86 

MODULE  TYPE:  PROCESS   VERS  3.0 

PURPOSE:  MODEL  THE  RADAR  SCHEDULER  FUNCTION 

NAME:  SEARCH  MANAGEMENT  ...  SRCM.LIB 


--  The  purpose  of  this  module  is  to  manage  the 

--  request  of  search  and  special  request  radar 

--  events.   The  current  design  processes  static 

--  data  for  the  Radar  Scheduler  Test  Harness. 

pragma  arithcheck(off ) ;  pragma  debug(off); 

pragma  enumtab( off ) ;    bragma  rangecheck(off ) 
(?  pragma  arithcheck(on)  ;  pragma  debugi'on)  ; 
£  pragma  enumtao^on) ;    pragma  rangecheck(on) ■ 

PACKAGE  3 rem  IS 

PROCEDURE  searchmgmt; 

END  srem; 
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--  OWNER:  AEGIS  MODELING  GROUP 

~  DATE  OF  LAST  UPDATE  :  30  Sep  86 

--  MODULE  TYPE:  PROCESS   VERS  3.0 

--  PURPOSE:  MODEL  THE  RADAR  SCHEDULER  FUNCTION 

--  NAME:  SEARCH  MANAGEMENT  ...  SRCM.PKG 


--  The  purpose  of  this  module  is  to  manage  the 
--  request  of  search  and  special  request  radar 
--  events.   The  current  design  processes  static 
--  data  for  the  Radar  Scheduler  Test  Harness. 

pragma  arithcheck(off ) ;  pragma  debug(off'); 
pragma  enumtab(off) ;    pragma  rangechecfc(off) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on) ; 

@  pragma  enumcaoi on) ;    pragma  rangecheck(on) ; 

WITH  global, tabO , smml ,smm2 ; 

PACKAGE  BODY  srcm  IS 

USE  global, tabO, smml ,smm2; 

PROCEDURE  searchmgmt  IS 

Lquad:  INTEGER- 

TYPE  BeamCount  IS  ARRAY(1..2)  OF  INTEGER; 

bm  ctr:  3eamCount; 

ppl,rnum,i:  INTEGER; 


BEGIN 


--  not  initialized  for  test  purposes,  taken  from  smml 
.cuad:  = 

:-  0; 
:=  0; 


■-  bm_ctr(l) 
■-  bm_ctr(2) 


sm_init;  --  from  smml.pkg 

FOR  i  IN  1.. infinity  LOOP 
await(s_pid,es_id, i) ; 

--  traverse  the  radar  event  priority  list 

WHILE  (ppl  /=  0)  LOOP 

IF  ((pri^lst(ppl) .que_id  =  search)  OR 

(pri_lst(ppl) .que_id  =  special_request) )  THEN 

fill_que(pri_lst(ppl)) ; 

END  IF; 

--  point  to  the  nest  priority  in  the  list 
ppl:=  pri_lst(ppl) .nxt; 
END  LOOP; 
END  LOOP; 
END  searchmgmt; 


END  srcm; 
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--  AEGIS  MODELING  GROUP 

--  DATE  OF  LAST  UPDATE:  31  AUG  86 

--  MODULE  TYPE:  SEARCH  MANAGEMENT  MODULE   vers  2.0 

--  PURPOSE:  INITIALIZE  THE  SEARCH  EVENT  QUEUES  IN  THE 

PRIORITY  LIST 
--  NAME:  SEARCH  MANAGEMENT  INITIALIZATION  ...  SMM1.LIB 

--  This  module  is  executed  once.   Its  purpose  is  to  allocate 
--  memory  for  search  nodes  (Table  1)  and  create  empty  request 
--  queues  for  each  search  and  special  request  radar  event  in 
--  the  Radar  Event  Priority  List  (Table  0) . 

pragma  arithcheck(off ) ;  pragma  debug(off); 

pragma  enumtab(ofr) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on) ; 
d  pragma  enumtab(on);    pragma  rangecheck(on) ; 

PACKAGE  smml  IS 

PROCEDURE  sm_init; 

END  smml ; 
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--  AEGIS  MODELING  GROUP 

--  DATE  OF  LAST  UPDATE:  26  Nov  86 

--  MODULE  TYPE:  SEARCH  MANAGEMENT  MODULE   vers  2.0 

--  PURPOSE:  INITIALIZE  THE  SEARCH  EVENT  QUEUES  IN  THE 

PRIORITY  LIST 
--  NAME:  SEARCH  MANAGEMENT  INITIALIZATION  ...  SMM1.PKG 

--  This  module  is  executed  once.   Its  purpose  is  to  allocate 

--  memory  for  search  nodes  (Table  1)  and  create  empty  request 

--  queues  for  each  search  and  special  request  radar  event  in 

--  the  Radar  Event  Priority  List  (Table  0) . 

pragma  arithcheck(off ) ;  pragma  debug(off ) ; 

pragma  enumtabfoff) ;    oragma  rangechecki off ) ; 
@  p'ragma  anthcheciu  on)  ;  pragma  debug"(on); 
@  pragma  enumcao(on);    pragma  rangecheck(on) ; 

WITH  tabO,tabi; 

PACKAGE  BODY  immi  13 

USE  tabO , tab!  ; 

PROCEDURE  sm_init  IS 

p,qptr:  SearchPtr:-  MEW  SearchNode; 
q:  5earchPtr; 

cur:  INTEGER:-  I ; 
node  ctr:  INTEGER; 
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--  traverse  the  Priority  Event  Lisz 
WHILE   ctr  /=  0)  LOOP  * 

CE  ,  (pri_Ist'.  etc  ;  .  que_id  =  search)  OR 

(prr_lst(ctr.)  .que_i.d  =  special_request))  THEN 

--  initialize  the  queue  to  length  -  max_nodes 

p:=  pri_lst(ctr) .que_ptr .Snode; 
node_ctr:=  0; 

WHILE  (node_ctr  <  pri_lst(ctr) .max_nodes)  LOOP 
node_ctr:=  node_ctr  +  1 ; 
q:=  NEW  SearchNode; 
q.info:=  NEW  SrchData; 
q.nxt:=  null; 

--  insert  at  the  end  of  event  queue  p 
IF  (p  =  null)  THEN 
p:=  g; 

bri_lst(ctr) .que_ptr. Snode :=  q; 
ELSE 

--  search  for  the  end  of  the  event  queue 

qptr:=  p; 

WHILE  (qptr.nxt  /=  null)  LOOP 

qptr:=  qptr.nxt; 
END  LOOP; 
--  insert  the  new  node 

¥3tr.nxt:=  q; 
F; 
END  LOOP; 
END  IF; 

ctr:=  pri_lst(ctr) .nxt; 
END  LOOP; 


END  sm_init; 
END  smml ; 
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—  OWNER:  AEGIS  MODELING  GROUP 

--  DATE  OF  LAST  UPDATE:  30  Sep  86 

--  MODULE  TYPE:  SEARCH  MANAGEMENT  SUBROUTINE   vers  2.0 

--  PURPOSE:  FILL  A  PRIORITY  LIST  SEARCH  QUEUE 

--  NAME:  FILL  SEARCH  QUEUE  ...SMM2.LIB 

--  This  routine  is  responsible  for  filling  a  priority 

--  event  queue  with  the  proper  synchronous  beam  request 

--  data.   It  executes  the  following  functions  for  each 

--  event  in  the  priority  list  which  corresponds  to  a 

--  Search  Management  event.   The  Fill  Search  Queue 

--  subroutine  calculates;  beam  mode,  unique  beam  id, 

--  beam  position  (azimuth  and  elevation),  instrumented 

--  range,  blanking  crates,  the  end  of  frame  indicator, 

--  the  Radar  Event  Priority  List  (Table  0)..--  and  requestor  identity. 

oraqma  arithcheck(off ) ;  pragma  debua(off); 

pragma  enumtaoi off ) ;    braama  ranqecneck(off ) ; 
@  pragma  arithcnecK( on; ;  pragma  debug(on); 
@  pragma  enumtab^on;  ,-    pragma  rangecheck^on) ; 

WITH  taoO: 

PACKAGE  3mm2  IS 

USE  tabO ; 

PROCEDURE  fill_que(pri_lst:  IN  OUT  PriLstPtr) ; 

TYPE  BeamCtrArray  IS  ARRAY(1..2)  OF  INTEGER; 
bm_ctr:  3eamCtrArray; 

Iquad:  INTEGER; 

END  smm2  ,- 
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--  OWNER:  AEGIS  MODELING  GROUP 

--  DATE  OF  LAST  UPDATE:  30  Sep  86 

--  MODULE  TYPE:  SEARCH  MANAGEMENT  SUBROUTINE   vers  2.0 

--  PURPOSE:  FILL  A  PRIORITY  LIST  SEARCH  QUEUE 

--  NAME:  FILL  SEARCH  QUEUE  ...SMM2.PKG 

--  This  routine  is  responsible  for  filling  a  priority 

--  event  queue  with  the  proper  synchronous  beam  request 

--  data.   It  executes  the  following  functions  for  each 

--  event  in  the  priority  list  which  corresponds  to  a 

--  Search  Management  event.   The  Fill  Search  Queue 

--  subroutine  calculates;  beam  mode,  unique  beam  id, 

--  beam  position  (azimuth  and  elevation),  instrumented 

--  range,  blanking  aates,  the  end  of  frame  indicator, 

--  the  Radar  Event  Priority  List  (Table  0).--  and  requestor  identity. 

pragma  arithcheckt  off )  ;  pragma  debug('off )  • 

pragma  enumtabi off ) ;    pragma  rangecheck(off ) ; 
@  p'ragma  arithcheck(cn) ;  pragma  debug(on)  ; 
@  pragma  enumtab(on);    pragma  rangecheck(on) ; 

WITH  global, tabO , tabl ,StrLib ; 

PACKAGE  30DY  smm2  IS 

USE  global, tabO, tab 1, St rLib; 

--  OWNER:  AEGIS  Modeiina  GrouD 

—  DATE  OF  LAST  UPDATE:  1  Oct' 36 

--  MODULE  TYPE:  Search  Management  subroutine 
--  PURPOSE:  Calculate  oeam  oosition 

—  NAME:  3eam  Position  ...  "5HM2A 

--  This  subroutine  calculates  the  beam  position  for  search  type 
--  beams  oased  on  the  calling  parameters  -  que  identity  and  random 
--  number,  the  last  quadrent  from  which  the  "beam  was  requested 
--  and  a  pointer  to  the  event  node  for  which  the  beam  position  is 
--  being  calculated. 

PROCEDURE  bm_pos(qid:.  IN  QueType ;rnum:  IN  INTEGER;  quad:  IN  OUT  INTEGER; 

p:  IN  OUT  SearchPtr)  IS 


BEGIN 

IF  (quad  =  1)  THEN 
3uad:=  3 

'=  2)  THEN 


ELSIF  (quad 
quad:=  4 

ELSIF  (quad 
quad:=  2 

ELSIF  (quad 
mad:=  1 


=  3)  THEN 
'=  4)  THEN 


quae 
END  IF; 

--  the  rest  of  this  module  has  not  been  implemented  yet 

END  bm_pos ; 
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OWNER:  AEGIS  Modeling  Group 

DATE  OF  LAST  UPDATE:  1  Oct  86 

MODULE  TYPE:  Search  Management  subroutine 

PURPOSE:  Calculate  end  of  frame  for  search  type  beams 

NAME:  End  Frame  ...  SMM2B 

This  subroutine  sets  the  end  of  frame  indication  flag  based  on 
its  input  parameters  -  beams  requested  and  event  identity.  An 
end  of  search  frame  is  indicated  for  the  horizon  search  event 
after  600  beams  have  been  scheduled.  An  end  of  search  frame  is 
indicated  for  the  above  horizon  search  after  3600  beams  have 
been  scheduled. 

FUNCTION  end_frm(num_bms,eid:  IN  INTEGER)  RETURN  BOOLEAN  IS 

BEGIN 

IF  ((eid  =  9)  AND  (num_bms  >=  600))  THEN 

RETURN  true; 
ELSIF  ((eid  =  22)  AND  (num_bms  >=  3600))  THEN 

RETURN  true; 
ELSE 

RETURN  false; 
END  IF; 
END  end  frm: 
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PROCEDURE  fill_que(pri_lst:  IN  OUT  PriLstPtr)  IS 

nodes_filld:  INTEGER :=  0; 

temp:  STRING (10); 

qptr,p:  SearchPtr:=  NEW  SearchNode,- 

rnum:  INTEGER; 


BEGIN 


--  set  event  que  status 
rnum:=  rand( ) ; 

IF  ( (pri  1st . que_id  =  special  request)  AND 
((rnum  MOD  max_pri)  /=  0]~)  THEN 

Dri  ist.status:^  false; 
ELSE 

ori  1st. status:-  true-; 
END.  IF  f 

pri_lst .que_ptr .Snoae . info :=  NEW  SrcnData; 

p. info :=  NEW  SrchData; 

qptr. info :=  MEW  SrchData; 

--  set  queue  pointer  to  event(trip)  pointer 

qptr ;-  pri_lst.que_ptr .Snode ; 

--  traverse  the  -avent  queue  and  fill  data  fields 

D:=  qptr; 

WHILE" ((p  /=  null)  AND  (pri_lst.  status) )  LOOP 

--  increment  the  numoer  of  nodes  filled  co  maintain  mique 
--  beam  id.  set  mode  to  event  base  pri 
nodes _fiild:=  ;iodes_fiild  -1-  I  ; 
p.  info. moos  :-  pri_'.3t  .o_pri; 

—  assign  uniaue  id  :oae  to  "his  beam 

o. info. bid:-  ExtracfcQpri  1st.  eventnm, 1, 1);   —  from  Striib 

temp:-  Int  to  Str(nodes_Filld) ;   --  from  StrLib 

IF  nodes_fIlld"  <  10  THEN 

temp:=  lnsert("0" , temp,l) ; 
END  IF; 
p. info. bid :=  Insert (temp, p. info. bid, 2) ; 

--  calculate  beam  position  -  1)  queue  id  #,  2)  random  #, 
--  3)  last  quadrant  entered,  4)  pointer  p 
rnum:=  randp  ; 
bm_pos(pri_lst.que_id,rnum, lquad,p) ; 


--  calculate  the  instrumented  range 

--  calculate  blanking  gates 

--  not  implemented  in  this  version 


--  calculate  end  of  frame 

IF  (pri  1st. que  id  =  search)  THEN 

IF  (pri_lst.~b__pri  =  9)  THEN    --  horizon  search  frame 
bm^ctr(l):=  bm^ctr(l)  +  1; 
p. Info.eof_indic :=  end_frm(bm  ctr(l),9); 
ELSE     --  above  horizon  search  "frame 
bm^.ctr(2):=  bm^ctr(2)  +  1; 
p.info.eof_indic:=  end_frm(bm_ctr(2) ,22) ; 
END  IF; 
ELSE       --  is  a  special  request  event 

p.info.eof_indic:=  false; 
END  IF; 

--  assign  requestor  id.  for  this  version  the  requestor  id 
--  is  assigned  the  value  of  the  beam  mode, 
p. info. req_id:=  p. info. mode; 

--  point  to  the  next  node  in  the  event  queue 
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p:=  p.nxt; 

END  LOOP; 

END  fill_que; 
END  smm2; 


142 


--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  29  Sep  86 

--  MODULE  TYPE:  Process  vers  3.0 

—  PURPOSE:  Model  the  Radar  Scheduler  function 

—  NAME:  Detection  Processing  ...  DRCM.LIB 

--  This  process  models  the  Detection  Processing  process  for  the 

--  purpose  of  modeling  its  interface  to  the  Radar  Scheduler  process 

pragma  arithcheck(off ) ;  pragma  debug(off); 

pragma  enumtab(of f ) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug ( on ) ; 
@  pragma  enumtab(on) ;    pragma  rangecheck(on) ; 

PACKAGE  drcm  IS 

PROCEDURE  detectproc; 

END  drcm; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  2  Dec  86 

--  MODULE  TYPE:  Process  vers  3.0 

--  PURPOSE:  Model  the  Radar  Scheduler  function 

--  NAME:  Detection  Processing  ...  DRCM.PKG 

--  This  process  models  the  Detection  Processing  process  for  the 

--  purpose  of  modeling  its  interface  to  the  Radar  Scheduler  process 

pragma  arithcheck(off ) ;  pragma  debug(off) ; 

pragma  enumtab(off ) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on) ; 
d  pragma  enumtab(on);    pragma  rangecheck(on) ; 

WITH  global, tab7,dpml; 

PACKAGE  BODY  drcm  15 

USE  global, tab7 ,dpml ; 

PROCEDURE  detectproc  IS 

Ctr,i:  INTEGER; 

BEGIN 

--  initialize  the  Track  File 
trkfilinit(ptrk) ;   --  See  DPM1.PKG 

"OR  i  IN  1 . . infinity  LOOP 
await ( d_pid, ed_£d, i) ; 
FOR  ctr  IN  1.  .126  LOOP 

null; 
END  LOOP; 
2ND  LOOP; 
END  detecuproc; 

END  drcm; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  1  Oct  86 

--  MODULE  TYPE:  Detection  Processing  routine  vers  2.0 

—  PURPOSE:  Initialize  the  Track  File 

--  NAME:  Track  File  Initialization  ...  DPMI. LIB 

--  This  module  creates  the  Track  File  (table  7)  used  by  the  test 
--  harness  to  provide  the  Radar  Scheduler  with  viable  track  data. 
--  This  subroutine  invokes  the  common  service  routine  -  rand  and 
--  the  Detection  Processing  subroutine  dpinend. 

pragma  arithcheck(off ) ;  pragma  debug(of f ) ; 

pragma  enumtabCof r) ;    pragma  rangecheck(of f ) ; 
@  pragma  arithcheck(on) ;  pragma  debug ( on ) ; 
@  pragma  enumtabCon);    pragma  rangecneck(on) ; 

WITH  nab? ; 

PACKAGE  dpml  IS 

USE  tab7; 

PROCEDURE  trkfilinit(ptrk:OUT  PtrTrkFile) ; 

2ND  dpmi ; 
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—  OWNER:  AEGIS  Modeling  Group 

—  DATE  OF  LAST  UPDATE:  2  Dec  86 

--  MODULE  TYPE:  Detection  Processing  routine  vers  2.0 

--  PURPOSE:  Initialize  the  Track  File 

--  NAME:  Track  File  Initialization  ...  DPM1.PKG 

--  This  module  creates  the  Track  File  (table  7)  used  by  the  test 
--  harness  to  provide  the  Radar  Scheduler  with  viable  track  data. 
--  This  subroutine  invokes  the  common  service  routine  -  rand  and 
--  the  Detection  Processing  subroutine  dpinend. 

pragma  arithcheck(off ) ;  pragma  debug(off<)  ; 

pragma  enumtab(off) ;    pragma  rangecheck(of f ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on) ; 
(§  pragma  enumtabvon) ;    pragma  rangecheck(on) ; 

WITH  global , tab4 , tao? , dpmia , Longops • 

PACKAGE  30DY  dpml  IS 

USE  global , iab4 , iab7 , dpmla , Longops ; 

PROCEDURE  trkfilinit(ptrk:  out  PtrTrkFile)  IS 

p::  PtrTrkFile; 
1 , j , rnum : INTEGER ; 

BEGIN 

ptrk:=null ; 

FOR  i  IN  L...A_toJ-t..op_docfc..mtrks  LOOP 

--  create  a  Track  File  node 
p-;=  MEW  Tri:Fiie; 
p.beam_data:=  MEW  TrkData; 

—  initialize  the  beam  data  based  on  a  ranaum  .lumoer 
rnum:=  rana( ) ; 

--  compute  the  mode  and  priority 

j :=  (rnum  MOD  22) ; 

IF  (((j  >=  4)  AND  (j  <=  8))  OR  ((j  >=  14)  AND  (j  <=  21)))  THEN 

p.Deam_data.mode :=  j; 
ELSE 

p.beam_data.mode :=  j  +  5; 
END  IF; 
p. beam_data. priority :=  p.beam_data.mode; 

--  these  flags  are  constant  valued 
p.beam_data.xmit_reqflg:=  true; 
p.beam_data.sim_tgt_Tlg:=  false; 

--  compute  log  amplitude  estimate  of  echo  signal 
p.beam_data. log_ampld_est :=  (rnum  MOD  100); 

--  compute  "z"  position 

?.beam  data. posit .z :=  (rnum  MOD  1000); 
F  (p.b"eam_data.posit.z  <  1000)  THEN 
p.beam_data. low_elev_trk_flg:=  true; 
ELSE 

p.beam_data. low_elev_trk_f lg:=  false; 
END  IF; 

--  compute  "x"  and  "y"  positions 
IF  ((rnum  MOD  2)  =  0)  THEN 

p.beam_data.posit.x:=  rnum; 

rnum:=  rand( ) ; 

p.beam_data.posit.y:=  0  -  rnum; 
ELSE 

p.beam_data.posit.y :=  rnum; 
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rnum:=  rand() ; 

p.beam_data.posit.x:=  0  -  rnum; 
END  IF; 

--  compute  slant  range 

p.beamldata. posit .slnt_rnge :=  Labs(Lmul(Lint(p.beam_data.posit.x) , 

Lint(p.beam_data.posit .y) ) ) ; 

--  compute  velocity  vectors 

p.beam_data.posit.x_dot :=  (p.beam_data.posit.x  MOD  (-200] 
p.beam_data.posit.y_dot :=  (p.beam_data.posit.y  MOD  (-200* 
p.beam_data.posit .z_dot :=  (p.beam_data.posit.z  MOD  (-10)); 
p.beam_data.posit. rge  dot:= 

L_to_int(Lmod(p  .b~eam_data  .posit .  slnt_rnge  ,Lint(-100) ) )  ; 

--  compute  cross  gate  bin  number 
p.beaml_data.xgte_Sin_num:=  (rnum  MOD  1000); 

--  assian  track  numbers 
p.beam_data.ctl  grp_trk_num:=  i; 
p.beam_data.ctsl:=  I  +  100; 

--  comDUte  track  transition  flag 
IF  (i.  <  5)  THEN 

o.beam  iata.tr:-;  rssitn  :iag:=  true; 
ELSE"      "        " 

o.beam_data.  trk_xsitn_flag:  =  false; 
END  IF; 

--  insert  the  track  node  at  the  end  of  the  TracK  File 

dpinend(p  .perk;  .-   --  from  dpmia.pKg 


END  LOOP; 
END  trkfilinit; 
END  dpml; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  1  Oct  86 

--  MODULE  TYPE:  Detection  Processing  subroutine  vers  2.0 

—  PURPOSE:  Insert  a  node  at  the  end  of  a  linked  list 

--  NAME:  dpinend  ...  DPM1A.LIB 

--  This  subroutine  has  two  parameters:  new_node  is  a  pointer  to  the 
--  node  which  is  to  be  inserted,  list  head  is  a  pointer  to  the  list 
--  to  which  the  node  is  to  be  inserted"  at  the  end  of. 

pragma  arithcheck(off ) ;  pragma  debug(off)  ; 

pragma  enumtab(off ) ;    pragma  rangecheck(of f ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on); 
@  pragma  enumtab(on) ;    pragma  rangecheck(on) ; 

WITH  tab7; 

PACKAGE  dpmla  IS 

USE  tab7; 

PROCEDURE  dpinend(new_node,list_head:  IN  OUT  PtrTrkFile); 

END  dpmla; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  1  Oct  86 

--  MODULE  TYPE:  Detection  Processing  subroutine  vers  2.0 

--  PURPOSE:  Insert  a  node  at  the  end  of  a  linked  list 

--  NAME:  dpinend  ...  DPM1A.PKG 

--  This  subroutine  has  two  parameters:  new_node  is  a  pointer  to  the 
--  node  which  is  to  be  inserted,  list  head  is  a  pointer  to  the  list 
--  to  which  the  node  is  to  be  inserted"  at  the  end  of. 

pragma  arithcheck(off ) ;  pragma  debug(off}; 

pragma  enumtab(of f ) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debugs  on); 
(§  pragma  enumtabion);    pragma  rangecheck(on)  • 

WITH  tab  7 - 

PACKAGE  30DY  dpmla  IS 

USE  tab7; 

PROCEDURE  dpinend(new_node,list_head:  IN  OUT  PtrTrkFile)  IS 

tp:  PtrTrkFile:-  MEW  TrkFiie  ; 

BEGIN 

:iev_node . nxt_trk : -  null ; 

—  check  for  an  ^mocv  list 
IF  (list  head  =  null")  THEM 

lisc32aa;-  new  node-; 
SLSE 

--  nearer,  for  the  ^na  of   the  list 

tp:=    _-.3-_:;eadr 

'WILE      tp7nxt_trk     =  null)    LOOP 
tp:=  tp.nxt  trk; 

END  LOOP; 

--  insert  the  new  node  at  the  end  of  the  list 
tp.nxt_trk:=  new_node ; 
END  IF; 

END  dpinend; 

END  dpmla; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  3  Sep  86 

—  MODULE  TYPE:  process  vers  3.0 

--  PURPOSE:  Model  the  Radar  Scheduler  Function 

—  NAME:  Switch  Action  And  Display  Processing  ...  ARCM.LIB 

--  This  process  is  a  single  thread  module  which  models  the  Switch 
--  Action  And  Display  module  on  the  INTELLEC[tm]  MDS  system. 

pragma  arithcheck(off ) ;  pragma  debug(of f) ; 

pragma  enumtab(off ) ;    pragma  rangecheck(of f ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on); 
d  pragma  enumtab(on);    pragma  rangecheck(on) ; 

PACKAGE  a rem  IS 

PROCEDURE  swtchactdply; 

ZND  a  rem,- 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  3  Oct  86 

--  MODULE  TYPE:  process  vers  3.0 

--  PURPOSE:  Model  the  Radar  Scheduler  Function 

--  NAME:  Switch  Action  And  Display  Processing  ...  ARCM.PKG 

--  This  process  is  a  single  thread  module  which  models  the  Switch 
--  Action  And  Display  module  on  the  INTELLEC[tm]  MDS  system. 

pragma  arithcheck(off ) ;  pragma  debug(off)); 

pragma  enumtab(off ) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on); 
@  pragma  enumtab(on) ;    pragma  rangecheck(on) ; 

WITH  sadml , global, tab4; 

PACKAGE  BODY  a rem  IS 

USE  sadml, global, tab4; 

PROCEDURE  swtchactdply  IS 

ctr,i:  INTEGER; 

3EGIN 

—  execute  operator  interface  .nodule  ffrom  sadmi.pkgj 
oimt'A_to_R.op_doct.mtr]-:s  ,  A_co_R.op_doct.mmtvis , 
A_to_R.op_.doct..  dp  ly_rect]"; 

--  initialize  Radar  Ivent  Priority  List 
ipl;    --  from  global. pKg 

FOR  i  IN  1..-.  infinity  LOOP 

await(a_pid, ea_id, i) ; 
FOR  ctr  IN  1.  .126  LOOP 

null; 
END  LOOP; 

END  LOOP; 

END  swtchactdply; 

END  arcm; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  3  Sep  86 

--  MODULE  TYPE:  process  vers  2.0 

--  PURPOSE:  Model  the  Radar  Schedular  function 

--  NAME:  Track  Management  ..  TRCM.LIB 

--  The  purpose  of  this  module  is  to  manage  the  request  of  track  and 
--  missile  radar  events.  The  current  design  produces  static  data  for 
--  the  radar  scheduler  Test  Harness. 

pragma  arithcheck(off ) ;  pragma  debug(off ) ; 

pragma  enumtab(off ) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on); 
@  pragma  enumtab(on) ;    pragma  rangecheck(on) ; 

PACKAGE  trcm  IS 

PROCEDURE  trackmgmt; 

END  trcm; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  3  Oct  86 

--  MODULE  TYPE:  process  vers  2.0 

--  PURPOSE:  Model  the  Radar  Schedular  function 

--  NAME:  Track  Management  ..  TRCM.PKG 

--  The  purpose  of  this  module  is  to  manage  the  request  of  track  and 
--  missile  radar  events.  The  current  design  produces  static  data  for 
--  the  radar  scheduler  Test  Harness. 

pragma  arithcheck(off ) ;  pragma  debug(off ) ; 

pragma  enumtab(off ) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on) ; 
@  pragma  enumcab(on);    pragma  rangecheck(on) ; 

WITH  giobal . tabO , ^ab2 . tab? . :mmi , 5  trLib ; 

PACKAGE  BODY  "rem  IS 

USE  giobal , iabO , tab2 , cab? , tmml , 3  trLib ; 

PROCEDURE  trackmgmt  IS 

i,ppl:  INTEGER: 

node  :tr:  INTEGER: 

temol  STRING (10); 

p  :  T r kP  t r :  -  NEW  Tr ac  :<No de  : 

q:  ?trTrKfiie:=  'JEW  TrkFile; 

BEGIN 

tm_inic ; 

FOR  i  IN  1 . . infinity  LOOP 

--  wait  for  the  Viaar  _ood  avenc  "alue 

await( t_pid. at__a. i) ; 

--  traverse  ~.":e  .-aaar  -ivent.  ~nori::y  list 

on  1 :  = 

WHILE  vppl  /=  0)  LOOP 

IF  ( (prills t (ppl) .que_id  =  track)  OR 

(pri_lst(ppl) .que_id  =  missile))  THEN 
—  traverse  the  event  queue  and  Track  File 

node_ctr:=  0; 

p:=  pri  lst(ppl) .que  otr .Tnode ; 

q:=  ptrk";     --  ptrK  from  global. lib 

WHILE  ((q  /=  null)  AND  (p  /=  null)  AND 

(node  ctr  <  pri_lst(ppl) .max_nodes) )  LOOP 
--  identify  this  event 

IF  (q.beam_data.mode  =  pri_lst(ppl) .b_pri)  THEN 
node_ctr:=  node_ctr  +  1; 

--  set  track  node  mode 

p. info. mode :=  pri_lst(ppl) .b_pri; 

--  set  unique  beam  identifier 
temp:=  Int_to_Str(node_ctr) ; 
IF  node_ctr  <  10  THEN 

temp:=  lnsert("0" , temp,l) ; 
END  IF; 

p.info.bid:=  Extract(pri_lst(ppl) . eventnm, 1,1); 
p.info.bid:=  Insert( temp, p. info. bid, 2) ; 

p.info.p_trk:=  q; 

p.info.p_trk.beam_data.bid:=  p. info. bid; 
pri_lst(ppl) .status :=  true; 

--  reset  pointers 

p:=  p.nxt; 
END  IF; 
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q:=  q.nxt_trk; 
END  LOOP; 
IF  (p  /=  null)  THEN 

p. info.p_trk:=  null; 
END  IF; 

END  IF; 

ppl:=  pri_lst(ppl) .nxt ; 

END  LOOP;    --  end  traverse  priority  list 

END  LOOP;   --  end  for  loop 

END  trackmgmt; 

JND  trcm; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  3  Sep  86 

--  MODULE  TYPE:  Track  Management  Module  vers  2.0 

--  PURPOSE:  Initialize  track  events  in  the  Radar  Event  Priority  List 

--  NAME:  Track  Management  Initialize  ..  TMM1.LIB 

--  The  purpose  of  this  module  is  to  allocate  memory  for  track  nodes 

--  (table  2)  and  create  empty  request  queues  for  each  search  and 

--  special  request  event  in  the  Radar  Event  Priority  List  (table  0). 

pragma  arithcheck(off ) ;  pragma  debug(off) ; 

pragma  enumtab(of f ) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on); 
@  pragma  enumtab(on);    pragma  rangecheck(on) ; 

PACKAGE  tnunl  IS 

PROCEDURE  tm_mit; 

END  tmml; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  30  Nov  86 

--  MODULE  TYPE:  Track  Management  Module  vers  2.0 

--  PURPOSE:  Initialize  track  events  in  the  Radar  Event  Priority  List 

--  NAME:  Track  Management  Initialize  ..  TMM1.PKG 

--  The  purpose  of  this  module  is  to  allocate  memory  for  track  nodes 

--  (table  z)  and  create  empty  request  queues  for  each  search  and 

--  special  request  event  in  the  Radar  Event  Priority  List  (table  0). 

pragma  arithcheck(off ) ;  pragma  debug(off) ; 

pragma  enumtab(off ) ;    pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug(on); 
@  pragma  enumtab(on) ;    pragma  rangecheck(on) ; 

WITH  tabO, tab2, tab?; 

PACKAGE  BODY  tmml  IS 

USE  tab0,tab2,tab7; 

PROCEDURE  tm_init  IS 

qptr,p:  TrkPtr:=  MEW  TrackNode; 
q:  TrkPtr; 

ppi:  INTEGER :=  I; 

node_ctr :  INTEGER ; 


BEGIN 


--  traverse  the  Radar  Event  Priority  List 
WHILE  (ppl  /=  0)  LOOP 

IF  ( (pri_lst(pol) . aue_id  =  -rack)  OR 

(prf_lst(ppt)  .que_id  =  missile))  THEN 

p:=  pri_lst(ppl) .que_ptr .Tnode; 
node_ctr:=  0; 

WHILE  (node_ctr  <  pri_lst(ppl) .max_nodes)  LOOP 

node_ctr:=  node  ctr  +  1; 
q-.=  NEW  TrackNode; 
q.info.p_trk:=  NEW  TrkFile; 
q.info.p_trk.beam_data:=  NEW  TrkData; 
q.nxt:=  null; 

--  insert  node  at  end  of  event  queue 
IF  (p  =  null)  THEN 

P==  9;  , 

bri_Ist(ppl) .que_ptr. Tnode :=  q; 
ELSE 

WHILE  (qptr.nxt  /=  null)  LOOP 

qptr:=  qptr.nxt; 
END  LOOP; 
qptr.nxt:=  q; 
END  IF; 

END  LOOP; 

END  IF; 

ppl:=  pri_lst(ppl) .nxt; 


END  LOOP; 
END  tm_init; 
END  tmml; 
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APPENDIX  E 
SAMPLE  RADAR  SCHEDULER  OUTPUT 

* *************************** *** ** ***************  ******* 

**************  AEGIS  AN/SPY-1A  ************** 
**************  RADAR  SCHEDULER  PROGRAM  ************** 
******************************************************* 

Instructions  to  the  Operator: 

Input  the  number  of  tracics  to  be  initialised: 

NUMBER  OF  TRACKS  >  50 

Input  the  number  of  scheduling  intervals  to  be  run: 

NUMBER  OF  INTERVALS  >  100 

Define  interval  lispiay  delay  period: 

SKIP  INTERVALS ,0 


3EGIN  EXECUTION 


Completed  interval:  1.0 

Completed  interval:  20 

Completed  interval:  30 

Completed  interval:  40 

Completed  interval:  50 

Completed  interval:  50 

Completed  interval:  70 

Completed  interval:  80 

Completed  interval:  90 

Completed  interval:  100 
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REQUESTED  BEAMS  FOR  SCHEDULER  INTERVAL:     10 

A-EVENT  -  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 

B-EVENT  -  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 

C-EVENT  -  SPECIAL  TEST 

NO  REQUESTS  THIS  INTERVAL 

G-EVENT  -  HIGH  PRI  TRACK  TRANSITION 
BEAM  ID       G01  G02  G03  G04  G05 
QUEUE  POSIT      12    3    4    5 

I -EVENT  -  HORIZON  SEARCH 

BEAM  ID       101  102  103  104  105  106  107  108  !09  110 

QUEUE  ?OSIT      1    2        3    4    5    6    T       Q.  -9'  10 

F-EVENT  -  PRE -ENGAGED  HOSTILE  TARGET 
3EAM  ID       ?01  FQ2  F03  F04  F05 
QUEUE  POSIT      12    3    4    5 

E-EVENT  -  OWN  5H-2  MISSILE  GUIDANCE 
3EAM  ID       301  302 
QUEUE  POSIT      i    2 

D-EVENT  -  ENGAGED  HOSTILE  TARGET 
BEAM  ID       D01  302  D03  304  D05 
QUEUE  POSIT      12    3    4    5 

H- EVENT  -  HIGH  PRI  TRACK  CONFIRMATION 
3EAM  ID       HOI  HO 2 
QUEUE  POSIT      L    1 

J-EVENT  -  SPECIAL  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 

K-EVENT  -  SPECIAL  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 

L-EVENT  -  SPECIAL  MANUAL  SCAN 

NO  REQUESTS  THIS  INTERVAL 

M-EVENT  -  SPECIAL  TARGET  ACQUISITION 

NO  REQUESTS  THIS  INTERVAL 

N-EVENT  -  CONFIRMED  HOSTILE  TRACK 
BEAM  ID       N01  N02  N03  N04 
QUEUE  POSIT      12    3    4 

O-EVENT  -  ASSUMED  HOSTILE  TRACK 
BEAM  ID       001  002  003  004  005 
QUEUE  POSIT      12    3    4    5 

P-EVENT  -  UNEVALUATED  TRACK 
BEAM  ID       P01  P02 
QUEUE  POSIT     1    2 

Q-EVENT  -  CONTROLLED  FRIENDLY  TRACK 
BEAM  ID       Q01  Q02  Q03  Q04 
QUEUE  POSIT     12    3    4 

V-EVENT  -  ABOVE  HORIZON  SEARCH 

BEAM  ID       V01  V02  V03  V04  V05  V06  V07  V08  V09  V10 

QUEUE   POSIT  123456789      10 
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R-EVENT  -  TRACK  CONFIRMATION 
BEAM  ID       R01  R02  R03  R04  R05 
QUEUE  POSIT     12    3   4    5 


S-EVENT  -  TRACK  TRANSITION 
BEAM  ID       SOI 
QUEUE  POSIT      1 

T-EVENT  -  ASSUMED  FRIENDLY  TRACK 
BEAM  ID       T01 
QUEUE  POSIT      1 

U-EVENT  - 
BEAM  ID 

queue  ?os: 

CONFIRMED  FRIENDLY  TRACK 

U01  U02 
CT     1   2 

W-EVENT  -  SPECIAL  ABOVE  HORIZON  SEARCH 
BEAM  ID       W01  W02  W03  W04  W05  W06 
QUEUE  POSIT      12    3    4    5    6 

X-EVENT  - 

SIMULATION  DWELL 

NO  REQUESTS  THIS  INTERVAL 

Y- EVENT  - 

DIAGNOSTIC  DWELL 

NO  REQUESTS  THIS  INTERVAL 

Z- EVENT  - 

DUMMY  DWELL 

NO  REQUESTS  THIS  INTERVAL 

SCHEDULED 

DWELLS  FOR  SCHEDULER  INTERVAL: 

1C 

i 

3EAM  ID 
RESOURCES 
DWELL  it 

GOl  G02  G03  G04  G05  101  102 

93   36   "9  n2      65   52   59 
12    3    4    5    5    7 

:03 

56 
3 

104 

53 

9 

135 
50 
10 

BEAM  ID 
RESOURCES 
DWELL  # 

106  107  108  109  110  111  F01 
47   44   41   38   35   32   25 
11   12   13   14   15   16   17 

F02 
18 
18 

F03 
11 
19 

F04 

4 

20 

BEAM  ID 
RESOURCES 
DWELL  # 

V01 

1 

21 
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REQUESTED  BEAMS  FOR  SCHEDULER  INTERVAL:     20 

A-EVENT  -  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 

B-EVENT  -  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 

C-EVENT  -  SPECIAL  TEST 

NO  REQUESTS  THIS  INTERVAL 

F-EVENT  -  PRE-ENGAGED  HOSTILE  TARGET 
BEAM  ID       F01  F02  F03  F04  F05 
QUEUE  POSIT     12    3    4    5 

E-EVENT  -  OWN  5M-2  MISSILE  GUIDANCE 
BEAM  ID       E01  S02 
QUEUE  POSIT      1    2 

I -EVENT  -  HORIZON  SEARCH 

BEAM  ID       101  102  103  104  105  106  107  108  109  110 

QUEUE    POSIT  123456789      10 

?- EVENT  -  "DEVALUATED  TRACK 
BEAM  ID        P01  ?02 
QUEUE  POSIT      1    2 

O-EVENT  -  CONTROLLED  FRIENDLY  TRACK 
3EAM  ID       001  002  Q03  004 
QUEUE  POSIT      12    3-4 

R- EVENT  -  TRACK  CONFIRMATION 
3EAM  ID       R01  R02  R03  R04  R05 
QUEUE  POSIT      12    3    4    5 

S -EVENT  -  TRACK  TRANSITION 
BEAM  ID       SOI 
QUEUE  POSIT      1 

T-EVENT  -  ASSUMED  FRIENDLY  TRACK 
BEAM  ID       T01 
QUEUE  POSIT      1 

U-EVENT  -  CONFIRMED  FRIENDLY  TRACK 
BEAM  ID       U01  U02 
QUEUE  POSIT      1    2 

D-EVENT  -  ENGAGED  HOSTILE  TARGET 
BEAM  ID       D01  D02  D03  D04  D05 
QUEUE  POSIT     12   3   4   5 

O-EVENT  -  ASSUMED  HOSTILE  TRACK 
BEAM  ID       001  002  003  004  005 
QUEUE  POSIT      12    3    4    5 

N-EVENT  -  CONFIRMED  HOSTILE  TRACK 
BEAM  ID       N01  N02  N03  N04 
QUEUE  POSIT      12    3    4 

H-EVENT  -  HIGH  PRI  TRACK  CONFIRMATION 
BEAM  ID       HOI  H02 
QUEUE  POSIT     1    2 

G-EVENT  -  HIGH  PRI  TRACK  TRANSITION 
BEAM  ID       G01  G02  G03  G04  G05 
QUEUE  POSIT     12   3   4   5 
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V-EVENT  -  ABOVE  HORIZON  SEARCH 

BEAM  ID       V01  V02  V03  V04  V05  V06  V07  V08  V09  VIO 

QUEUE   POSIT  123456789      10 


J-EVENT  - 

SPECIAL  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 

K-EVENT  - 

SPECIAL  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 

L-EVENT  - 

SPECIAL  MANUAL  SCAN 

NO  REQUESTS  THIS  INTERVAL 

M- EVENT  - 

SPECIAL  TARGET  ACQUISITION 
WO  REQUESTS  THIS  INTERVAL 

W- EVENT  - 
BEAM  ID 

queue  ?os: 

SPECIAL  ABOVE  HORIZON  SEARCH 
W01  WO 2  WO 3  W04  WO 5  WO 6 

CT     I    I    2    4    5    6 

X-EVENT  - 

SIMULATION  DWELL 

NO  REQUESTS  THIS  INTERVAL 

Y- EVENT  - 

DIAGNOSTIC  DWELL 

MO  REQUESTS  THIS  INTERVAL 

Z- EVENT  - 

DUMMY  DWELL 

:J0  REQUESTS  THIS  INTERVAL 

SCHEDULED 

DWELLS  FOR  SCHEDULER  INTERVAL 

>  - 

20 

3EAM  ID 
RESOURCES 
DWELL  # 

F01  F02  F03  F04  F05  101  I 

33   35   79   72   65   58 
:    I    4   5   6 

02 

51 

101 

48 

5 

102 

45 
9 

103 
42 
1.0 

BEAM  ID 
RESOURCES 
DWELL  # 

104  105  106  107  108  109  I 
39   36   33   30   27   24 
11   12   13   14   15   16 

10 
21 
17 

111 
18 
18 

P01 
11 
19 

PC2 

4 

20 

BEAM  ID 
RESOURCES 
DWELL  # 

V01 

1 

21 
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REQUESTED  BEAMS  FOR  SCHEDULER  INTERVAL:     30 

A-EVENT  -  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 

B-EVENT  -  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 

C-EVENT  -  SPECIAL  TEST 

NO  REQUESTS  THIS  INTERVAL 

F-EVENT  -  PRE-ENGAGED  HOSTILE  TARGET 
BEAM  ID       F01  F02  F03  F04  F05 
QUEUE  POSIT      12    3    4    5 

E-EVENT  -  OWN  SM-2  MISSILE  GUIDANCE 
BEAM  ID       101  E02 
QUEUE  POSIT      i    2 

D- EVENT  -  ENGAGED  HOSTILE  TARGET 
BEAM  ID       D01  D02  D03  D04  D05 
QUEUE  POSIT      12    3    4    5 

H-EVENT  -  HIGH  PRI  TRACK  CONFIRMATION 
SEAM  ID       HOI  HO 2 
QUEUE  POSIT      1    2 

U.-EVENT  -  CONFIRMED  FRIENDLY  TRACK 
BEAM  ID       fJOl  U02 
QUEUE  POSIT      L    I 

I-EVENT  -  HORIZON  .SEARCH 

BEAM  ID        121  102  103  104  105  106  107  108  109  110 

OUEUE  POSIT      .1:4557    39   10 

5 -EVENT  -  TRACK  TRANSITION 
BEAM  ID       SOI 
QUEUE  POSIT      1 

T-EVENT  -  ASSUMED  FRIENDLY  TRACK 
BEAM  ID       T01 
QUEUE  POSIT      1 

R-EVENT  -  TRACK  CONFIRMATION 
BEAM  ID       R01  R02  R03  R04  R05 
QUEUE  POSIT     12   3   4    5 

G-EVENT  -  HIGH  PRI  TRACK  TRANSITION 
BEAM  ID       G01  G02  G03  G04  G05 
QUEUE  POSIT      12    3    4    5 

Q-EVENT  -  CONTROLLED  FRIENDLY  TRACK 
BEAM  ID       Q01  Q02  Q03  Q04 
QUEUE  POSIT      12    3    4 

P-EVENT  -  UNEVALUATED  TRACK 
BEAM  ID       P01  P02 
QUEUE  POSIT      1    2 

O-EVENT  -  ASSUMED  HOSTILE  TRACK 
BEAM  ID       001  002  O03  004  005 
QUEUE  POSIT     12   3   4   5 

V-EVENT  -  ABOVE  HORIZON  SEARCH 

BEAM  ID       V01  V02  V03  V04  V05  V06  V07  V08  V09  V10 

QUEUE   POSIT  123456789      10 
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N-EVENT  -  CONFIRMED  HOSTILE  TRACK 
BEAM  ID       N01  N02  N03  N04 
QUEUE  POSIT      12    3    4 


J-EVENT  -  SPECIAL  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 

K-EVENT  -  SPECIAL  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 

L-EVENT  -  SPECIAL  MANUAL  SCAN 

NO  REQUESTS  THIS  INTERVAL 

M-EVENT  -  SPECIAL  TARGET  ACQUISITION 

NO  REQUESTS  THIS  INTERVAL 

W-EVENT  -  SPECIAL  ABOVE  HORIZON  SEARCH 
BEAM  ID       WOl  W02  W03  W04  W05  W06 
QUEUE  POSIT     12    3   4    5    6 

X-EVENT  -  SIMULATION  DWELL 

NO  REQUESTS  THIS  INTERVAL 

Y-EVENT  -  DIAGNOSTIC  DWELL 

NO  REQUESTS  THIS  INTERVAL 

Z- EVENT  -  DUMMY  DWELL 

NO  REQUESTS  THIS  INTERVAL 


SCHEDULED  DWELLS  "OR  SCHEDULER  INTERVAL:     30 

SEAM  ID  F01  F02  F03  704  F05  SOI  £02  D01  D02  D03 

RESOURCES  32   36   79   72   65   53   51   44   37   30 

DWELL  #  123456739   10 

BEAM  ID  D04  D05  HOI  H02 

RESOURCES  23   16   9    2 

DWELL  #  11   12   13   14 
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REQUESTED  BEAMS  FOR  SCHEDULER  INTERVAL:     40 

A-EVENT  -  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 

B-EVENT  -  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 

C-EVENT  -  SPECIAL  TEST 

NO  REQUESTS  THIS  INTERVAL 

E-EVENT  -  OWN  SM-2  MISSILE  GUIDANCE 
BEAM  ID       E01  E02 
QUEUE  POSIT      1    2 

I -EVENT  -  HORIZON  SEARCH 

BEAM  ID       101  102  103  104  105  106  107  108  109  110 

QUEUE   POSIT  123456739      10 

D-EVENT  -  ENGAGED  HOSTILE  TARGET 
BEAM  ID       D01  D02  D03  D04  D05 
QUEUE  POSIT     12    3   4    5 

H- EVENT  -  HIGH  PRI  TRACK  CONFIRMATION 
3EAM  ID       HOI  H02 
QUEUE  ?OSIT      1    2 

G- EVENT  -  HIGH  PRI  TRACK  TRANSITION 
BEAM  ID       G01  G02  G03  G04  GO 5 
QUEUE  POSIT      12    3    4    5 

U- EVENT  -  CONFIRMED  FRIENDLY  TRACK 
BEAM  ID       U01  U02 
QUEUE  POSIT      1    2 

F-EVENT  -  PRE-ENGAGED  HOSTILE  TARGET 
BEAM  ID       F01  F02  F03  F04  F05 
QUEUE  POSIT      12    3    4    5 

S -EVENT  -  TRACK  TRANSITION 
BEAM  ID       SOI 
QUEUE  POSIT     1 

T-EVENT  -  ASSUMED  FRIENDLY  TRACK 
BEAM  ID       T01 
QUEUE  POSIT     1 

R-EVENT  -  TRACK  CONFIRMATION 
BEAM  ID       R01  R02  R03  R04  R05 
QUEUE  POSIT     12   3   4   5 

Q-EVENT  -  CONTROLLED  FRIENDLY  TRACK 
BEAM  ID       Q01  Q02  Q03  Q04 
QUEUE  POSIT     12    3    4 

P-EVENT  -  UNEVALUATED  TRACK 
BEAM  ID       P01  P02 
QUEUE  POSIT     1    2 

O-EVENT  -  ASSUMED  HOSTILE  TRACK 
BEAM  ID       001  002  003  004  005 
QUEUE  POSIT      12    3    4    5 

V-EVENT  -  ABOVE  HORIZON  SEARCH 

BEAM  ID       V01  V02  V03  V04  V05  V06  V07  V08  V09  V10 

QUEUE   POSIT  123456789      10 


164 


N-EVENT  -  CONFIRMED  HOSTILE  TRACK 
BEAM  ID       N01  N02  N03  N04 
QUEUE  POSIT      12    3    4 


J-EVENT  - 

SPECIAL  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 

K-EVENT  - 

SPECIAL  TARGET 
NO  REQUESTS 

DEFINITION 
THIS  INTERVAL 

L-EVENT  - 

SPECIAL  MANUAL 
NO  REQUESTS 

SCAN 
THIS 

INTERVAL 

M- EVENT  - 

SPECIAL  TARGET 
NO  REQUESTS 

ACOUI 

mis 

SITION 
INTERVAL 

W- EVENT  - 
3EAM  ID 

queue  ?os: 

SPECIAL  ABOVE  HORIZON  SEARCH 

WOl  WO 2  WO 3  WO 4  WO 5  WO 6 
IT      12    3    4    5    6 

X- EVENT  - 

SIMULATION  DWELL 

NO  REQUESTS  THIS 

INTERVAL 

7- EVENT  - 

DIAGNOSTIC  DWELL 

MO  REQUESTS  THIS 

INTERVAL 

Z -EVENT  - 

DUMMY  DWELL 

NO  REQUESTS 

THIS 

INTERVAL 

SCHEDULED 

DWELLS  FOR  SCHEDULES 

.  INTERVAL 

■ 

4C 

BEAM  ID 
RESOURCES 
DWELL  # 

EOl  E02  101 

93   36   33 
2 

102 
30 

4 

103  E04  I 
77   74 

5    6 

05 

71 

106 
63 

n 

o 

107 
65 

9 

108 
62 

10 

BEAM  ID 
RESOURCES 
DWELL  # 

109  110  111 
59   56   53 
11   12   13 

D01 
46 
14 

D02  DOS  E 
39   32 
15   16 

04 
25 
17 

D05 
18 
18 

HOI 
11 
19 

HO  2 

4 

20 

BEAM  ID 
RESOURCES 
DWELL  # 

V01 

1 

21 
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REQUESTED  BEAMS  FOR  SCHEDULER  INTERVAL:     50 

A-EVENT  -  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 

B-EVENT  -  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 

C-EVENT  -  SPECIAL  TEST 

NO  REQUESTS  THIS  INTERVAL 

D-EVENT  -  ENGAGED  HOSTILE  TARGET 
BEAM  ID       D01  D02  D03  D04  DOS 
QUEUE  POSIT      12    3    4    5 

H-EVENT  -  HIGH  ?RI  TRACK  CONFIRMATION 
SEAM  ID       HOI  HO 2 
3UEUE  POSIT     1    2 

I-EVENT  -  HORIZON  SEARCH 

BEAM  ID       101  102  103  104  105  106  107  103  109  110 

QUEUE    POSIT  123455739      10 

0- EVENT  -  ASSUMED  HOSTILE  TRACK 

3EAM  ID       001  002  003  004  005 
QUEUE  POSIT      12    3+5 

G-EVENT  -  HIGH  PRI  TRACK  TRANSITION 
BEAM  ID        301  G02  003  004  005 
2UEUE  POSIT     L   £   3-   4-   5 

P- EVENT  -  DEVALUATED  TRACK 
BEAM  ID       P01  ?02 
QUEUE  POSIT      .    2 

7- EVENT  -  PRE-ENGAGED  HOSTILE  TARGET 
BEAM  ID       F01  F02  F03  FG4  F05 
QUEUE  POSIT     12    3   4   5 

Q-EVENT  -  CONTROLLED  FRIENDLY  TRACK 
BEAM  ID       Q01  Q02  Q03  Q04 
QUEUE  POSIT      12    3    4 

N-EVENT  -  CONFIRMED  HOSTILE  TRACK 
BEAM  ID       N01  N02  N03  N04 
QUEUE  POSIT      12    3    4 

E-EVENT  -  OWN  SM-2  MISSILE  GUIDANCE 
BEAM  ID       E01  E02 
QUEUE  POSIT      1    2 

U-EVENT  -  CONFIRMED  FRIENDLY  TRACK 
BEAM  ID       U01  U02 
QUEUE  POSIT      1    2 

S-EVENT  -  TRACK  TRANSITION 
BEAM  ID       SOI 
QUEUE  POSIT      1 

T-EVENT  -  ASSUMED  FRIENDLY  TRACK 
BEAM  ID       T01 
QUEUE  POSIT      1 

V-EVENT  -  ABOVE  HORIZON  SEARCH 

BEAM  ID       V01  V02  V03  V04  V05  V06  V07  V08  V09  V10 

QUEUE   POSIT  123456789      10 
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R-EVENT  -  TRACK  CONFIRMATION 
BEAM  ID       R01  R02  R03  R04  R05 
QUEUE  POSIT     12    3   4    5 


J-EVENT  - 

SPECIAL  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 

K-EVENT  - 

SPECIAL  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 

L-EVENT  - 

SPECIAL  MANUAL  SCAN 

NO  REQUESTS  THIS  INTERVAL 

M-EVENT  - 

SPECIAL  TARGET  ACQUISITION 
NO  REQUESTS  THIS  INTERVAL 

W-EVENT  -  SPECIAL  ABOVE  HORIZON  SEARCH 
BEAM  ID       W01  W02  W03  W04  WO 5  W06 
QUEUE  POSIT      12    3    4    5    6 

X-EVENT  - 

SIMULATION  DWELL 

NO  REQUESTS  THIS  INTERVAL 

7- EVENT  - 

DIAGNOSTIC  DWELL 

NO  REQUESTS  THIS  INTERVAL 

Z- EVENT  - 

DUMMY  DWELL 

NO  REQUESTS  THIS  INTERVAL 

SCHEDULED 

DWELLS  FOR  SCHEDULER  INTERVAL: 

5C 

BEAM  ID 
RESOURCES 
DWELL  # 

DOi  D02  D03  D04  D05  HOI  H02 
93   86   79   72   55   53   51 

12    3    4    5    6    7 

101 

43 

3 

102 

45 
g 

102 
42 
LO 

BEAM  ID 
RESOURCES 
DWELL  # 

104  105  106  107  108  109  110 
39   36   33   30   27   24   21 
11   12   13   14   15   16   17 

111 
18 
18 

001 
11 
19 

002 

4 

20 

BEAM  ID 
RESOURCES 
DWELL  # 

V01 

1 

21 
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REQUESTED  BEAMS  FOR  SCHEDULER  INTERVAL:     60 

A-EVENT  -  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 

B-EVENT  -  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 

C-EVENT  -  SPECIAL  TEST 

NO  REQUESTS  THIS  INTERVAL 

H-EVENT  -  HIGH  PRI  TRACK  CONFIRMATION 
BEAM  ID       HOI  H02 
QUEUE  POSIT      1    2 

G- EVENT  -  HIGH  PRI  TRACK  TRANSITION 
BEAM  ID       G01  G02  G03  G04  GO 5 
QUEUE  POSIT      12    3    4    5 

I-EVENT  -  HORIZON  SEARCH 

BEAM  ID       101  102  103  104  105  106  107  108  109  110 

QUEUE   POSIT  123456789      10 

Q-EVENT  -  CONTROLLED  FRIENDLY  TRACK 
SEAM  ID       001  002  003  004 
QUEUE  POSIT      12    3    4 

R-EVENT  -  TRACK  CONFIRMATION 
SEAM  ID       R01  R02  R03  R04  R05 
QUEUE  POSIT      12    3    4    3 

5- EVENT  -  TRACK  TRANSITION 
BEAM  ID       SOI 
QUEUE  POSIT      1 

T- EVENT  -  ASSUMED  FRIENDLY  TRACK 
BEAM  ID       T01 
QUEUE  POSIT      1 

F-EVENT  -  PRE-ENGAGED  HOSTILE  TARGET 
BEAM  ID       F01  F02  F03  F04  F05 
QUEUE  POSIT     12   3   4   5 

E-EVENT  -  OWN  SM-2  MISSILE  GUIDANCE 
BEAM  ID       E01  E02 
QUEUE  POSIT     1    2 

D-EVENT  -  ENGAGED  HOSTILE  TARGET 
BEAM  ID       D01  D02  D03  D04  D05 
QUEUE  POSIT      12    3    4    5 

P-EVENT  -  UNEVALUATED  TRACK 
BEAM  ID       P01  P02 
QUEUE  POSIT      1    2 

O-EVENT  -  ASSUMED  HOSTILE  TRACK 
BEAM  ID       001  002  003  004  005 
QUEUE  POSIT     12    3   4    5 

N-EVENT  -  CONFIRMED  HOSTILE  TRACK 
BEAM  ID       N01  N02  N03  N04 
QUEUE  POSIT      12    3    4 

V-EVENT  -  ABOVE  HORIZON  SEARCH 

BEAM  ID       V01  V02  V03  V04  V05  V06  V07  V08  V09  V10 

QUEUE   POSIT  123456789      10 
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U-EVENT  -  CONFIRMED  FRIENDLY  TRACK 
BEAM  ID       U01  U02 
QUEUE  POSIT      1    2 

J-EVENT  -  SPECIAL  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 

K-EVENT  -  SPECIAL  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 

L-EVENT  -  SPECIAL  MANUAL  SCAN 

NO  REQUESTS  THIS  INTERVAL 

M-EVENT  -  SPECIAL  TARGET  ACQUISITION 

NO  REQUESTS  THIS  INTERVAL 

W- EVENT  -  SPECIAL  ABOVE  HORIZON  SEARCH 
BEAM  ID       W01  W02  W03  W04  W05  W06 
QUEUE  POSIT      i    2    3    4    5    6 

X-EVEMT  -  SIMULATION  DWELL 

NO  REQUESTS  THIS  INTERVAL 

T- EVENT  -  DIAGNOSTIC  DWELL 

MO  REQUESTS  THIS  INTERVAL 

2-EVENT  -  DUMMY  DWELL 

MO  REQUESTS  THIS  INTERVAL 


SCHEDULED  DWELLS  TOR  SCHEDULER  INTERVAL.     60 

3EAM  ID  HOI  HO 2  001  002  003  004  GO 5  101  102  103 

RESOURCES  03   36   "9  ~:2  55   53  31   43   45   42 

DWELL  ft  I    2    2    4  5    o  3910 

BEAM  ID  104  105  106  107  103  109  110  111  Q01  Q02 

RESOURCES  39   36   33   30  27   24  21   18   11    4 

DWELL  #  11   12   13   14  15   16  17   18   19   20 

BEAM  ID  V01 

RESOURCES  1 

DWELL  #  21 
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REQUESTED  BEAMS  FOR  SCHEDULER  INTERVAL:     70 

A-EVENT  -  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 

B-EVENT  -  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 

C-EVENT  -  SPECIAL  TEST 

NO  REQUESTS  THIS  INTERVAL 

D-EVENT  -  ENGAGED  HOSTILE  TARGET 
BEAM  ID       D01  D02  D03  D04  D05 
QUEUE  POSIT      12    3    4    5 

H-EVENT  -  HIGH  ?RI  TRACK  CONFIRMATION 
3EAM  ID       HOI  HO 2 
QUEUE  POSIT      1    2 

S-EVENT  -  HIGH  ?RI  TRACK  TRANSITION 
BEAM  ID       G01  G02  G03  G04  G05 
QUEUE  POSIT     12    3   4    5 

F-EVENT  -  PRE- ENGAGED  HOSTILE  TARGET 
3EAM  ID       F01  F02  F03  704  F05 
QUEUE  POSIT     .2:^5 

E-EVENT  -  OWN  SM-2  MISSILE  GUIDANCE 
3EAM  ID       301  302 
QUEUE  POSIT      L    2 

I -EVENT  -  HORIZON  SEARCH 

3EAM  ID       101  102  103  104  105  106  107  108  109  110 

QUEUE  POSIT      12    1^56"    3    9   10 

S-EVENT  -  TRACK  TRANSITION 
3EAM  ID       301 
QUEUE  POSIT      1 

U-EVENT  -  CONFIRMED  FRIENDLY  TRACK 
BEAM  ID       U01  U02 
QUEUE  POSIT      1    2 

T-EVENT  -  ASSUMED  FRIENDLY  TRACK 
BEAM  ID       T01 
QUEUE  POSIT      1 

R-EVENT  -  TRACK  CONFIRMATION 
BEAM  ID       R01  R02  R03  R04  R05 
QUEUE  POSIT     12   3   4   5 

Q-EVENT  -  CONTROLLED  FRIENDLY  TRACK 
BEAM  ID       Q01  Q02  Q03  Q04 
QUEUE  POSIT     12   3   4 

P-EVENT  -  UNEVALUATED  TRACK 
BEAM  ID       P01  P02 
QUEUE  POSIT      1    2 

O-EVENT  -  ASSUMED  HOSTILE  TRACK 
BEAM  ID       001  002  003  004  005 
QUEUE  POSIT     12   3   4   5 

N-EVENT  -  CONFIRMED  HOSTILE  TRACK 
BEAM  ID       N01  N02  N03  N04 
QUEUE  POSIT      12    3    4 
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V-EVENT  -  ABOVE  HORIZON  SEARCH 

BEAM  ID       V01  V02  V03  V04  V05  V06  V07  V08  V09  VIO 

QUEUE   POSIT  123456789      10 

J-EVENT  -  SPECIAL  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 

K-EVENT  -  SPECIAL  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 

L-EVENT  -  SPECIAL  MANUAL  SCAN 

NO  REQUESTS  THIS  INTERVAL 

M-EVENT  -  SPECIAL  TARGET  ACQUISITION 

NO  REQUESTS  THIS  INTERVAL 

W-EVENT  -  SPECIAL  ABOVE  HORIZON  SEARCH 
BEAM  ID       W01  W02  W03  W04  W05  W06 
QUEUE  POSIT      12    3    4    5    6 

X-EVENT  -  SIMULATION  DWELL 

NO  REQUESTS  THIS  INTERVAL 

Y-EVENT  -  DIAGNOSTIC  DWELL 

NO  REQUESTS  THIS  INTERVAL 

Z- EVENT  -  DUMMY  DWELL 

NO  REQUESTS  THIS  INTERVAL 


SCHEDULED  DWELLS  FOR  SCHEDULER  INTERVAL:     70 

3EAM  ID  D01  D02  DOS  D04  D05  HOI  HO 2  G01  G02  G03 

RESOURCES  93   36   79   72   65   53   31   44   37   30 

DWELL  &  2    3    4    5    6    7    3    9   10 

BEAM  ID  G04  G05  F01  F02 

RESOURCES  23   16    9    2 

DWELL  #  11   12   13   14 
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REQUESTED  BEAMS  FOR  SCHEDULER  INTERVAL:     80 

A-EVENT  -  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 

B-EVENT  -  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 

C-EVENT  -  SPECIAL  TEST 

NO  REQUESTS  THIS  INTERVAL 

G-EVENT  -  HIGH  PRI  TRACK  TRANSITION 
BEAM  ID       G01  G02  G03  G04  G05 
QUEUE  POSIT     12    3    4   5 

F-EVENT  -  PRE-ENGAGED  HOSTILE  TARGET 
3EAM  ID       F01  F02  F03  F04  F05 
QUEUE  POSIT      12    3    4    5 

E-EVEMT  -  OWN  SM-2  MISSILE  GUIDANCE 
BEAM  ID       E01  E02 
QUEUE  POSIT      1    2 

D-EVENT  -  ENGAGED  HOSTILE  TARGET 
BEAM  ID       001  D02  D03  004  005 
QUEUE  POSIT      12    3    4    5 

M-EVENT  -  CONFIRMED  HOSTILE  TRACK 
BEAM  ID       M01  N02  M03  M04 
QUEUE  POSIT      12    3    4 

I -EVENT  -  HORIZON  SEARCH 

BEAM  ID        101  102  103  104  105  106  107  108  109  110 

QUEUE    POSIT  123455739      10 

0- EVENT  -  ASSUMED  HOSTILE  TRACK 
BEAM  ID       001  002  003  004  005 
QUEUE  POSIT     12   3   4    5 

H-EVENT  -  HIGH  PRI  TRACK  CONFIRMATION 
BEAM  ID       HOI  H02 
QUEUE  POSIT      1    2 

U-EVENT  -  CONFIRMED  FRIENDLY  TRACK 
BEAM  ID       U01  U02 
QUEUE  POSIT      1    2 

P -EVENT  -  UNEVALUATED  TRACK 
BEAM  ID       P01  P02 
QUEUE  POSIT      1    2 

S-EVENT  -  TRACK  TRANSITION 
BEAM  ID       SOI 
QUEUE  POSIT      1 

T-EVENT  -  ASSUMED  FRIENDLY  TRACK 
BEAM  ID       T01 
QUEUE  POSIT      1 

V-EVENT  -  ABOVE  HORIZON  SEARCH 

BEAM  ID       V01  V02  V03  V04  V05  V06  V07  V08  V09  V10 

QUEUE   POSIT  123456789      10 

R-EVENT  -  TRACK  CONFIRMATION 
BEAM  ID       R01  R02  R03  R04  R05 
QUEUE  POSIT     12   3   4   5 
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Q-EVENT  -  CONTROLLED  FRIENDLY  TRACK 
BEAM  ID       001  Q02  Q03  Q04 
QUEUE  POSIT      12    3    4 


J-EVENT  -  SPECIAL  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 

K-EVENT  -  SPECIAL  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 

L-EVENT  -  SPECIAL  MANUAL  SCAN 

NO  REQUESTS  THIS  INTERVAL 

M-EVENT  -  SPECIAL  TARGET  ACQUISITION 

NO  REQUESTS  THIS  INTERVAL 

W- EVENT  -  SPECIAL  ABOVE  HORIZON  SEARCH 
3EAM  ID       W01  W02  W03  W04  W05  W06 

QUEUE  POSIT     12    3    4    5    6 

K-EVENT  -  SIMULATION  DWELL 

NO  REQUESTS  THIS  INTERVAL 

Y- EVENT  -  DIAGNOSTIC  DWELL 

MO  REQUESTS  THIS  INTERVAL 

3- EVENT  -  DUMMY  DWELL 

MO  REQUESTS  THIS  INTERVAL 


SCHEDULED  DWELLS  "OR  SCHEDULER  INTERVAL :  30 

BEAM  ID  SOI  G02  303  304  DOS  F01  F02  F03  F04  F05 

RESOURCES  33   36   79  r2      65   53   51   44   37   30 

DWELL  i  L   2   3   4-   5    6..   7    8.   9   10 

BEAM  ID  E01  £02  D01  D02 

RESOURCES  23   16    9    2 

DWELL  #  11   12   13   14 
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REQUESTED  BEAMS  FOR  SCHEDULER  INTERVAL:     90 

A- EVENT  -  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 

B-EVENT  -  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 

C-EVENT  -  SPECIAL  TEST 

NO  REQUESTS  THIS  INTERVAL 

F-EVENT  -  PRE-ENGAGED  HOSTILE  TARGET 
BEAM  ID       F01  F02  F03  F04  F05 
QUEUE  POSIT     12    3    4    5 

E-EVENT  -  OWN  SM-2  MISSILE  GUIDANCE 
3EAM  ID       EOl  £02 
QUEUE  POSIT      L    2 

D- EVENT  -  ENGAGED  HOSTILE  TARGET 
BEAM  ID       D01  D02  D03  D04  D05 
QUEUE  POSIT      12    3    4    5 

H-EVENT  -  HIGH  PRI  TRACK  CONFIRMATION 
3EAM  ID       HOI  HO 2 
QUEUE  POSIT      I    2 

P- EVENT  -  UNEVALUATSD  TRACK 
BEAM  ID       POl  ?02 
QUEUE  ?OSIT      1    2 

I -EVENT  -  HORIZON  SEARCH 

3EAM  ID       101  102  103  104  105  106  107  103  109  110 

2UEUE  POSIT      12    3    15    5    7    3    9   10 

G- EVENT  -  HIGH  PRI  TRACK  TRANSITION 
3EAM  ID       G01  G02  G03  G04  G05 
QUEUE  POSIT     12   3   4   5 

O-EVENT  -  ASSUMED  HOSTILE  TRACK 
BEAM  ID       001  002  003  004  005 
QUEUE  POSIT     12   3   4   5 

N-EVENT  -  CONFIRMED  HOSTILE  TRACK 
BEAM  ID       N01  N02  N03  N04 
QUEUE  POSIT      12    3    4 

Q-EVENT  -  CONTROLLED  FRIENDLY  TRACK 
BEAM  ID       Q01  Q02  Q03  Q04 
QUEUE  POSIT      12    3    4 

U-EVENT  -  CONFIRMED  FRIENDLY  TRACK 
BEAM  ID       U01  U02 
QUEUE  POSIT      1    2 

R-EVENT  -  TRACK  CONFIRMATION 
BEAM  ID       R01  R02  R03  R04  R05 
QUEUE  POSIT     12   3   4   5 

S-EVENT  -  TRACK  TRANSITION 
BEAM  ID       SOI 
QUEUE  POSIT      1 

V-EVENT  -  ABOVE  HORIZON  SEARCH 

BEAM  ID       V01  V02  V03  V04  V05  V06  V07  V08  V09  V10 

QUEUE   POSIT  123456789      10 
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T-EVENT  -  ASSUMED  FRIENDLY  TRACK 
BEAM  ID       T01 
QUEUE  POSIT      1 


J-EVENT  - 

SPECIAL  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 

K- EVENT  - 

SPECIAL  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 

L-EVENT  - 

SPECIAL  MANUAL  SCAN 

NO  REQUESTS  THIS  INTERVAL 

M-EVENT  - 

SPECIAL  TARGET  ACQUISITION 
NO  REQUESTS  THIS  INTERVAL 

W-EVENT  -  SPECIAL  ABOVE  HORIZON  SEARCH 
BEAM  ID       W01  WO 2  WO 3  W04  WO 5  WO 6 
QUEUE  POSIT      12    3    4    5    6 

X-EVENT  - 

SIMULATION  DWELL 

NO  REQUESTS  THIS  INTERVAL 

Y-  EVENT  - 

DIAGNOSTIC  DWELL 

NO  REQUESTS  THIS  INTERVAL 

Z- EVENT  - 

DUMMY  DWELL 

NO  REQUESTS  THIS  INTERVAL 

SCHEDULED 

DWELLS  FOR  SCHEDULER  INTERVAL: 

90 

3EAM  ID 
RESOURCES 

DWELL  4 

FOl  F02  F03  F04  F05  501  E02 

93   36   79   72   55   53   51 

12    3    4    5    5    7 

DOl  D02  D03 

44   37   30 

3    9   10 

BEAM  ID 
RESOURCES 
DWELL  # 

D04  D05  HOI  H02 
23   16    9    2 
11   12   13   14 

175 


REQUESTED  BEAMS  FOR  SCHEDULER  INTERVAL:    100 

A- EVENT  -  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 

B-EVENT  -  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 

C-EVENT  -  SPECIAL  TEST 

NO  REQUESTS  THIS  INTERVAL 

H-EVENT  -  HIGH  PRI  TRACK  CONFIRMATION 
BEAM  ID       HOI  H02 
QUEUE  POSIT      1    2 

I -EVENT  -  HORIZON  SEARCH 

SEAM  ID       101  102  103  104  105  106  107  108  109  110 

QUEUE    POSIT  123456789      10 

E-EVENT  -  OWN  SM-2  MISSILE  GUIDANCE 
BEAM  ID       E01  E02 
QUEUE  POSIT      1    2 

Q- EVENT  -  CONTROLLED  FRIENDLY  TRACK 
3EAM  ID       001  002  Q03  Q04 
QUEUE  POSIT      12    3    4 

S- EVENT  -  TRACK  TRANSITION 
3EAM  ID       501 
QUEUE  POSIT      1 

R- EVENT  -  TRACK  CONFIRMATION 
3EAM  ID       R01  R02  R03  R04  R05 

QUEUE  POSIT      12    3    4    5 

D- EVENT  -  ENGAGED  HOSTILE  TARGET 
BEAM  ID       D01  D02  D03  D04  D05 
QUEUE  POSIT     12    3   4    5 

G-EVENT  -  HIGH  PRI  TRACK  TRANSITION 
BEAM  ID       G01  G02  G03  G04  G05 
QUEUE  POSIT     12   3   4   5 

P-EVENT  -  UNEVALUATED  TRACK 
BEAM  ID       P01  P02 
QUEUE  POSIT      1    2 

F-EVENT  -  PRE-ENGAGED  HOSTILE  TARGET 
BEAM  ID       F01  F02  F03  F04  F05 
QUEUE  POSIT     12    3   4   5 

O-EVENT  -  ASSUMED  HOSTILE  TRACK 
BEAM  ID       001  002  003  004  005 
QUEUE  POSIT      12    3    4    5 

N-EVENT  -  CONFIRMED  HOSTILE  TRACK 
BEAM  ID       N01  N02  N03  N04 
QUEUE  POSIT      12    3    4 

U-EVENT  -  CONFIRMED  FRIENDLY  TRACK 
BEAM  ID       U01  U02 
QUEUE  POSIT      1    2 

T-EVENT  -  ASSUMED  FRIENDLY  TRACK 
BEAM  ID       T01 
QUEUE  POSIT      1 
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V-EVENT  -  ABOVE  HORIZON  SEARCH 

BEAM  ID       V01  V02  V03  V04  V05  V06  V07  V08  V09  V10 

QUEUE   POSIT  123456789      10 

J-EVENT  -  SPECIAL  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 

K-EVENT  -  SPECIAL  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 

L-EVENT  -  SPECIAL  MANUAL  SCAN 

NO  REQUESTS  THIS  INTERVAL 

M-EVENT  -  SPECIAL  TARGET  ACQUISITION 

NO  REQUESTS  THIS  INTERVAL 

W-EVENT  -  SPECIAL  ABOVE  HORIZON  SEARCH 
3EAM  ID       W01  W02  W03  W04  WO 5  W06 

QUEUE  POSIT      12    3    4    5    8 

X- EVENT  -  SIMULATION  DWELL 

NO  REQUESTS  THIS  INTERVAL 

Y-EVENT  -  DIAGNOSTIC  DWELL 

NO  REQUESTS  THIS  INTERVAL 

Z- EVENT  -  DUMMY  DWELL 

NO  REQUESTS  THIS  INTERVAL 


SCHEDULED  DWELLS  FOR  SCHEDULER  INTERVAL:    100 

3EAM  ID  HOI  H02  101  102  103  104  105  106  107  108 

RESOURCES  93   36  32  30   77   74   71   68   65   32 

DWELL  {*  1 .2  3  4:   5'   6.   T   8   9   10 

BEAM  ID  109  110  111  E01  E02  Q01  Q02  Q03  Q04  SOI 

RESOURCES  59   56  53  46   39   32   25   18   11    4 

DWELL  #  11   12  13  14   15   16   17   18   19   20 

BEAM  ID  V01 

RESOURCES  1 

DWELL  #  21 
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